On 10/19/19 7:17 AM, Bernhard Voelker wrote:
On 10/18/19 10:07 AM, Stefan Seyfried wrote:
Am 18.10.19 um 09:10 schrieb Simon Lees:
In addition cli apps like htop and mc ship a desktop file that will launch the app in your terminal emulator of choice.
kernel-default.desktop m)
Nice one. ;-)
But getting constructive again: IMO it does not make sense to add desktop files for such kind of packages.
Agreed, it only makes sense to add them for packages that people would want to find searching via groups.
Why not simply use the hierarchical Group: values as tags? I admit I have a quite narrow view of the packages, but e.g. 'coreutils' has "System/Base" ... and both "System" and "Base" is true.
I no your taking this as an example but I am not really sure people would search for things like coreutils via groups (there is already a significant number of packages that require it anyway). A big part of my proposal is to only provide group info for things that make sense to be found with group info, which means libraries and other core dependencies that people will have installed anyway shouldn't really have groups because it will just add "noise"
A tool using tags could simply read existing Groups: values as separate tags. Of course, additional tags may be added - e.g. with a ' ' separator - like "Base System scripting". (Or continue using '/' as tag separator. Sounds pretty simple and straightforward.
It does sound simple until you look at the fact that what we have for current groups is a bit of a mess. For some things in the past we have had groups that are two fine grain, so you might find one piece of software in one group, but another similar piece of software that you'd expect to be in the same group in a different group. Equally in other places there haven't been enough groups so you get very large groups containing all sorts of semi relevant and sometimes not relevant software again making it pretty much useless. What we have currently doesn't provide a good starting point as such if we do something it would at this point be better to start from scratch. If we were to keep the group tag and manually populate it which many people are against (hence the consensus to remove it in may last year) I suggest we would be better off using the categories we have for desktop files as a starting point and think very hard about whether packages that don't fall into one of those categories even make sense to be searched by groups. So while that approach may sound straight forward it isn't really. -- 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