5:22 a.m.
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.
7:09 a.m.
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
11:17 a.m.
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
4:40 a.m.
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
11:24 a.m.
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: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11:21 a.m.
On Tue, Jul 15, 2014 at 5:39 PM, Daniel Vrátil <dvratil(a)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.
--
Regards,
Sudhir Khanger.
sudhirkhanger.com
https://github.com/donniezazen
9:27 a.m.
On 15 July 2014 13:09, Daniel Vrátil <dvratil(a)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.
2:37 a.m.
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>
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
4:38 p.m.
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
3563
days inactive
3571
days old
8 comments
6 participants
participants (6)
-
Dan Vratil -
Kevin Kofler -
Orion Poplawski -
Richard Hughes -
Sudhir Khanger -
Syam Krishnan