![](https://seccdn.libravatar.org/avatar/a4139df10120ce151e457fd1faff018d.jpg?s=120&d=mm&r=g)
On 10/21/19 6:49 PM, Ludwig Nussel wrote:
Bernhard Voelker schrieb:
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')?
Looking at the discussion here I can already foresee the next fights in submit requests where people argue over which tags to put on a package. So I wonder whether to maybe dodge that mine field completely and store tags aka groups outside of packages. Left for those to maintain who actually care. Technically we can generate additional information into the repo metadata. Translations are done that way for example and also EULAs for nonfree packages. Software.o.o could for example be used to allow users who are not packagers to modify tags. The existing group tags could still be used as starting point.
Beyond that it'd probably mean we could translate tags which would be useful for a number of users. Additionally we have a copy of all the spec files in factory from within the last month before groups started being removed so if someone wants to use that data as a starting point we can provide it without needing to keep it or getting maintainer to add it back into factory. -- 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