On 10/20/19 7:32 PM, Bernhard Voelker wrote:
On 2019-10-20 06:08, Simon Lees wrote:
On 10/19/19 6:32 PM, Bernhard Voelker wrote:
- gnome-calculator = Productivity || Scientific || Math - gedit = Productivity || Text || Editors
The three biggest issues here are some groups like System, Productivity, Base etc will have so many items they would basically be useless, I think Jan even suggested dropping the top level category for these reasons. Secondly because the current groups have so many issues its likely that you may not find all the calculators in the "Math" category for example, where as currently the desktop files are logically organized etc. Thirdly having groups for libraries, -lang packages and -devel packages means that users end up searching through hundreds of packages that aren't what they are looking for and should really only be installed by dependencies.
I think we're at the point where we should avoid mixing the 3 aspects:
a) What to store? I.e., what tags values should we have? Again, I think all of us said and repeated and repeated again that the current values are not ideal. How could they - considering that they have been a hierarchy instead of independent tags?
b) Where to store? As far as I can see, there are 2 suggestions: RPM's Group tag (keep it, but change from hierarchy to tag values), or desktop files. To my knowledge, only programs which have a GUI or would be run otherwise by clicking on something have a desktop files, right? So what about all the utilities for the command line (e.g. 'pv'), or packages which augment other tools ('geany-plugins')?
The suggestion was actually to populate the rpm group tag using data from the desktop file as part of the build process. This means the packager then doesn't need to worry about it in many cases and is less work. In such a case presuming geany-plugins are built in the same spec file as geany, then the build system can set the value to be the same. Many command line utilities do already ship desktop files its just some desktop's are configured not to show them, it is possible within the spec to create desktop files that are never shown in desktops which would be appropriate for many such CLI applications.
c) How to use it from a management tool? I think this question has been discussed very sparsely ... which I find strange because this is the only thing what matters for the user.
This I agree with and I mentioned this to Jan in the email that then spawned this thread. If the yast team decides they don't want to re implement such a view or if they decide they only want to do it with appstream meta data as some other desktops and distro's are doing we are right back at there being no point for this discussion. -- 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