Advice needed on dealing with kicad, kipi-plugins and kdepim

[Richard Hughes]

Hi all,

A few weeks ago we produced this:
https://docs.google.com/spreadsheets/d/1FBmdtwDH6WHaLBfy6yqYqjEd3IA5GBEDy...
which is a list of all the desktop applications and addons that share
package names in Fedora.

The core problem is that users click "Remove" on "Akonadi Console" in
either Apper or GNOME Software and then find that an application that
they wanted to keep "KOrganizer" has gone too! So they re-install
"KOrganizer" and the "Akonadi Console" item appears magically. The
confused user then files a bug :)

Splitting things up into subpackages containing the correct binary and
the .desktop file, depending on a -common package would fix things,
and is what most of the software in that shared document has already
done.

The alternative is to add NoDisplay=true to the desktop file for
something like Akonadi Console that might want to be hidden in the
menus, or blacklist akonadiconsole.desktop from the metadata parser
completely. The other fix we can do is to "merge" the child
applications into a parent application, e.g. we merged git-dag into
git-cola so only the latter is shown in the software center. This
isn't ideal as then you hide the very thing the user might be looking
for (although, we do inherit the merged applications keywords and
mimetypes for searching).

In an ideal world we should split up the kicad, kipi-plugins and
kdepim packages into 4+ subpackages each, but I wanted to know what
you all thought of the proposal before I filed a bug or worked on a
patch. Ideas welcome, thanks.

Richard.

[Dan Vratil]

On Tuesday 15 of July 2014 11:22:44 Richard Hughes wrote:
>  Hi all,
>  
>  A few weeks ago we produced this:
>  https://docs.google.com/spreadsheets/d/1FBmdtwDH6WHaLBfy6yqYqjEd3IA5GBEDyh-6
>  5FVnDMc/edit?usp=sharing which is a list of all the desktop applications and
>  addons that share package names in Fedora.
>  
>  The core problem is that users click "Remove" on "Akonadi Console"
> in
>  either Apper or GNOME Software and then find that an application that
>  they wanted to keep "KOrganizer" has gone too! So they re-install
>  "KOrganizer" and the "Akonadi Console" item appears magically. The
>  confused user then files a bug :)
>  
>  Splitting things up into subpackages containing the correct binary and
>  the .desktop file, depending on a -common package would fix things,
>  and is what most of the software in that shared document has already
>  done.
>  
>  The alternative is to add NoDisplay=true to the desktop file for
>  something like Akonadi Console that might want to be hidden in the
>  menus, or blacklist akonadiconsole.desktop from the metadata parser
>  completely. The other fix we can do is to "merge" the child
>  applications into a parent application, e.g. we merged git-dag into
>  git-cola so only the latter is shown in the software center. This
>  isn't ideal as then you hide the very thing the user might be looking
>  for (although, we do inherit the merged applications keywords and
>  mimetypes for searching).
>  
>  In an ideal world we should split up the kicad, kipi-plugins and
>  kdepim packages into 4+ subpackages each, but I wanted to know what
>  you all thought of the proposal before I filed a bug or worked on a
>  patch. Ideas welcome, thanks. 
Hi,

speaking with my KDE PIM developer hat on, I think it makes a lot of sense to 
actually split the package per-app, so we would have

kdepim-akonadiconsole (I'd actually prefer if this was not installed by 
default, so that people would not be tempted to play with it :P)
kdepim-akregator
kdepim-blogilo
kdepim-kaddressbook
kdepim-kjots
kdepim-kleopatra
kdepim-kmail
kdepim-knode
kdepim-knotes
kdepim-kontact
kdepim-korganizer
kdepim-libs (libs shared by multiple PIM apps)
kdepim-common (?) (shared executables, like incidenceeditor-ng, Akonadi 
agents, etc)

If others agree with this, I can help with figuring out the inter-
dependencies.

Can't speak for kipi-plugin and kicad, as I don't know much about those two.

Cao,
Daniel



>  
>  Richard.
>  _______________________________________________
>  kde mailing list
>  kde(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/kde
>  New to KDE4? - get help from http://userbase.kde.org 
-- 
Daniel Vrátil | dvratil(a)redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

[Syam Krishnan]

On 07/15/2014 05:39 PM, Daniel Vrátil wrote:
>  Hi,
>
>  speaking with my KDE PIM developer hat on, I think it makes a lot of sense to
>  actually split the package per-app, so we would have
>
>  kdepim-akonadiconsole (I'd actually prefer if this was not installed by
>  default, so that people would not be tempted to play with it :P)
>  kdepim-akregator
>  kdepim-blogilo
>  kdepim-kaddressbook
>  kdepim-kjots
>  kdepim-kleopatra
>  kdepim-kmail
>  kdepim-knode
>  kdepim-knotes
>  kdepim-kontact
>  kdepim-korganizer
>  kdepim-libs (libs shared by multiple PIM apps)
>  kdepim-common (?) (shared executables, like incidenceeditor-ng, Akonadi
>  agents, etc) 
One suggestion (apologies in advance if I've not understood it 
correctly). Why "kdepim-*" naming for applications? It might make sense 
for libraries, but not applications.
I think its better to just have kontact, korganizer etc. rather than 
with "kdepim-" prefix.

I think we had something like this for kate, okteta etc. which was 
sometimes irritating since one had to yum search for "*kate*" to figure 
out the package name for installation. Anyway, nowadays, its just kate 
and okteta, and I'm liking it.


Syam

[Sudhir Khanger]

On Tue, Jul 15, 2014 at 5:39 PM, Daniel Vrátil <dvratil(a)redhat.com&gt; wrote:
>  speaking with my KDE PIM developer hat on, I think it makes a lot of
> sense to
>  actually split the package per-app, so we would have 
This would also be preferred by folks who do not use certain
applications like Blogio, Akregator, etc. and thus do not want to
regularly update and maintain them on their systems.

-- 
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen

[Dan Vratil]

On Tuesday 15 of July 2014 21:47:32 Syam Krishnan wrote:
>  On 07/15/2014 05:39 PM, Daniel Vrátil wrote:
>  > Hi,
>  > 
>  > speaking with my KDE PIM developer hat on, I think it makes a lot of sense
>  > to actually split the package per-app, so we would have
>  > 
>  > kdepim-akonadiconsole (I'd actually prefer if this was not installed by
>  > default, so that people would not be tempted to play with it :P)
>  > kdepim-akregator
>  > kdepim-blogilo
>  > kdepim-kaddressbook
>  > kdepim-kjots
>  > kdepim-kleopatra
>  > kdepim-kmail
>  > kdepim-knode
>  > kdepim-knotes
>  > kdepim-kontact
>  > kdepim-korganizer
>  > kdepim-libs (libs shared by multiple PIM apps)
>  > kdepim-common (?) (shared executables, like incidenceeditor-ng, Akonadi
>  > agents, etc)
>  
>  One suggestion (apologies in advance if I've not understood it
>  correctly). Why "kdepim-*" naming for applications? It might make sense
>  for libraries, but not applications.
>  I think its better to just have kontact, korganizer etc. rather than
>  with "kdepim-" prefix.
>  
>  I think we had something like this for kate, okteta etc. which was
>  sometimes irritating since one had to yum search for "*kate*" to figure
>  out the package name for installation. Anyway, nowadays, its just kate
>  and okteta, and I'm liking it. 
I think that this would require having a spec file for each application, which 
would make updating and building a big pain, since whole KDE PIM would have to 
be built every time (please correct me if I'm wrong), because the entire KDE 
PIM is released as a single tarball. If we want to package these apps as 
subpackages in the same .spec file, the kdepim prefix cannot be avoided.

This is definitely going to change with KDE Applications 5 (or whetever this 
is going to be called), when each KDE PIM application will have it's own git 
repository and a release tarball. But this is still at least a year, maybe two 
years in future.

Dan

>  
>  
>  Syam
>  _______________________________________________
>  kde mailing list
>  kde(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/kde
>  New to KDE4? - get help from http://userbase.kde.org 
-- 
Daniel Vrátil | dvratil(a)redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

[Orion Poplawski]

On 07/16/2014 03:40 AM, Daniel Vrátil wrote:
>  On Tuesday 15 of July 2014 21:47:32 Syam Krishnan wrote:
> > On 07/15/2014 05:39 PM, Daniel Vrátil wrote:
> >> Hi,
> >>
> >> speaking with my KDE PIM developer hat on, I think it makes a lot of sense
> >> to actually split the package per-app, so we would have
> >>
> >> kdepim-akonadiconsole (I'd actually prefer if this was not installed by
> >> default, so that people would not be tempted to play with it :P)
> >> kdepim-akregator
> >> kdepim-blogilo
> >> kdepim-kaddressbook
> >> kdepim-kjots
> >> kdepim-kleopatra
> >> kdepim-kmail
> >> kdepim-knode
> >> kdepim-knotes
> >> kdepim-kontact
> >> kdepim-korganizer
> >> kdepim-libs (libs shared by multiple PIM apps)
> >> kdepim-common (?) (shared executables, like incidenceeditor-ng, Akonadi
> >> agents, etc)
> >
> > One suggestion (apologies in advance if I've not understood it
> > correctly). Why "kdepim-*" naming for applications? It might make sense
> > for libraries, but not applications.
> > I think its better to just have kontact, korganizer etc. rather than
> > with "kdepim-" prefix.
> >
> > I think we had something like this for kate, okteta etc. which was
> > sometimes irritating since one had to yum search for "*kate*" to figure
> > out the package name for installation. Anyway, nowadays, its just kate
> > and okteta, and I'm liking it.
>
>  I think that this would require having a spec file for each application, which
>  would make updating and building a big pain, since whole KDE PIM would have to
>  be built every time (please correct me if I'm wrong), because the entire KDE
>  PIM is released as a single tarball. If we want to package these apps as
>  subpackages in the same .spec file, the kdepim prefix cannot be avoided. 
No, you can name subpackages whatever you want, e.g.:

%package -n kmail

Note the "-n"


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                   http://www.nwra.com

[Richard Hughes]

On 15 July 2014 13:09, Daniel Vrátil <dvratil(a)redhat.com&gt; wrote:
>  speaking with my KDE PIM developer hat on, I think it makes a lot of
> sense to
>  actually split the package per-app, so we would have
>  If others agree with this, I can help with figuring out the inter-
>  dependencies. 
Works for me, do you have any spare cycles so we can have this split
by F21 alpha?

Thanks,

Richard.

[Dan Vratil]

On Thursday 17 of July 2014 15:27:01 Richard Hughes wrote:
>  On 15 July 2014 13:09, Daniel Vrátil <dvratil(a)redhat.com&gt;
> wrote:
>  > speaking with my KDE PIM developer hat on, I think it makes a lot of sense
>  > to actually split the package per-app, so we would have
>  > If others agree with this, I can help with figuring out the inter-
>  > dependencies.
>  
>  Works for me, do you have any spare cycles so we can have this split
>  by F21 alpha? 
Yeah, I'll look into it today.

Dan


>  
>  Thanks,
>  
>  Richard.
>  _______________________________________________
>  kde mailing list
>  kde(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/kde
>  New to KDE4? - get help from http://userbase.kde.org 
-- 
Daniel Vrátil | dvratil(a)redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348

[Kevin Kofler]

Hi,

Richard Hughes wrote:
>  which is a list of all the desktop applications and addons that
> share
>  package names in Fedora. 
For Kicad: This is not really a core KDE application, it just happens to be 
built on the KDE platform. I think kicad.desktop is clearly the main 
application there, and the others can be treated like git-dag (i.e., hidden 
in favor of kicad), but you'd better contact the maintainer directly. I'm 
not familiar with this application nor with what expectations its users have 
(i.e., whether they'll search for e.g. gerbview and expect to find it in 
Apper or not).

For kipi-plugins: In principle, that's not really an application, it's an 
addon package (for applications using libkipi, such as Gwenview or Digikam). 
Some addons can also be executed standalone, but that's not its primary 
purpose. I'm not sure how to best handle that either. It is probably 
possible to split every standalone application and maybe even every single 
plugin into separate subpackages, I'm just not sure it's a good idea.

And by the way, relying on proprietary web services such as Google Documents 
for Free Software development is a very bad idea. We have an ODF standard 
for a reason.

        Kevin Kofler