On 10/18/19 4:50 PM, Neal Gompa wrote:
On Fri, Oct 18, 2019 at 1:48 AM Simon Lees
wrote: Hi Jan
I was discussing this with a few people and we have come up with what we feel would be a better proposal in the long term, that is to populate the group tag from the desktop file category shipped with the package.
There are many advantages to this which I will get to but first i'll cover the fact that not every package ships a desktop file, in the end I think this is mostly a positive, the whole point of this mechanism is user discovery and there is a bunch of things such as libraries and devel packages that users shouldn't want to discover with groups we have package management for that. Similarly someone is unlikely to choose a virtualization hypervisor based off searching groups.
The one placed I can think of where some people might want some form of groups is for certain command line applications like editors etc if people want they can add a desktop file and set it not to show in desktops.
The most obvious benefit is this is a system we already expect people to maintain and its really obvious if its wrong. It also means that we are not depending on 1-2 people to check everything and keep it right because if you get sick or go on a holiday or decide to do something else there hasn't been much indication of others willing to step up and keep the groups running, its likely they will just fall out of maintenance and disappear.
It also has the advantage of well defined classifications that are shared across all parts of the distro such as desktop menu's etc, beyond that they are also generally shared across distro's for the most part again adding to the consistency. Between the "Standard" and "Technology" Categories it likely also has most of the info that you've suggested you want to include in tags.
So again I want to propose we drop the Group: from spec files and then move toward auto generating it from relevant desktop files as possible which will be much more maintainable and will save every one work (especially as its already been demonstrated that we have tools capable of dropping the group flag.
There is not a lot of value in the Group tag if non-GUI apps aren't categorized. Graphical applications already are sorted using AppStream metadata in software centers (GNOME Software, Plasma Discover, etc.). But if you were to use something like dnfdragora, Apper, or YaST, it wouldn't be particularly helpful. Moreover, people usually rely on the native package manager interfaces when trying to find things that aren't conventionally indexed (i.e. not graphical applications with desktop files and AppStream data).
If we're only doing GUI apps, let's not bother with the Group tag.
As it was pointed out in another thread the number of packages in openSUSE currently shipping AppStream meta data is still somewhat limited, it likely covers Gnome and KDE apps relatively well but many of the applications outside those projects are missing for example most if not all applications that ship with the enlightenment desktop don't have such metadata because upstream doesn't use it and no one got to contributing to that inside openSUSE yet. desktop files also don't need to just be for gui applications, there is no reason why you can't have desktop files for applications such as vim or emacs with the "NoDisplay" option set some cli applications may already be doing that to some extent. Mutt is an example of such an app. In addition cli apps like htop and mc ship a desktop file that will launch the app in your terminal emulator of choice. I don't think there is any value in categorizing things that aren't apps, (maybe beside desktops but thats better done with patterns anyway) and desktop files can happily do all applications where as i'm guessing AppStream doesn't. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B