Hi all,
A few weeks ago we produced this: https://docs.google.com/spreadsheets/d/1FBmdtwDH6WHaLBfy6yqYqjEd3IA5GBEDyh-6... 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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
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
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
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"
On Tue, Jul 15, 2014 at 5:39 PM, Daniel Vrátil dvratil@redhat.com 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.
On 15 July 2014 13:09, Daniel Vrátil dvratil@redhat.com 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.
On Thursday 17 of July 2014 15:27:01 Richard Hughes wrote:
On 15 July 2014 13:09, Daniel Vrátil dvratil@redhat.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
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
-
Dan Vratil -
Kevin Kofler -
Orion Poplawski -
Richard Hughes -
Sudhir Khanger -
Syam Krishnan