[opensuse-factory] Formal specification of tags as a replacement for groups
The Group: line in .spec files is a freeform text field that is used to declare categories that a browsing application can sort packages by. Historically, the Group: field value specified exactly one category out of a hierarchially-ordered tree of many categories such as: * Amusements * Games * 3D * Teachings * Productivity * Graphics * CAD (3D) * 2D Because a package may fit into multiple categories, this proposal suggests to move away from the hierarchial system and instead use a tag system as a base, wherein the Group: field is a space-separated list of keywords that characterize the package. This way, the "kate" package for example may be associated with the keywords "kde" and "editor" and the "gedit" package with "gnome" and "editor", such that a user browsing the software catalog can filter either by "kde" or "gnome" (depending on preference), or by "editor" (if it does not matter which UI) to discover packages he might be interested in. This tag system is inspired by those of freshmeat/freecode/freshcode.club and stackexchange.com. This tag system is already used by SUSE PackageHub, https://packagehub.suse.com/ . Experiments have shown (in both a POC and in PackageHub) that the words from the classic group list make for a good start, in other words, the existing classic groups as present in .spec files provide a starting point and thus do not qualify as "totally useless" as some opponents repeatedly claim. The new suggested tag list is even derived from the old list because it turns out it was not overly bad, it was just single-value. If and when a maintainer updates a package for some reason (version update, patch added, etc.), s/he can also update the Group: field "en passant" to become such a ws-separated tag list. There is no strict need to do a flag day or for replacing classic group values across the distribution all at once. Packages with the new system are already in the process of being delivered. For more details, confer with https://en.opensuse.org/openSUSE:Package_group_guidelines where a section on tags has been added. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Oct 17, 2019 at 01:32:29PM +0200, Jan Engelhardt wrote:
The Group: line in .spec files is a freeform text field that is used to declare categories that a browsing application can sort packages by.
Historically, the Group: field value specified exactly one category out of a hierarchially-ordered tree of many categories such as:
* Amusements * Games * 3D * Teachings * Productivity * Graphics * CAD (3D) * 2D
Because a package may fit into multiple categories, this proposal suggests to move away from the hierarchial system and instead use a tag system as a base, wherein the Group: field is a space-separated list of keywords that characterize the package. This way, the "kate" package for example may be associated with the keywords "kde" and "editor" and the "gedit" package with "gnome" and "editor", such that a user browsing the software catalog can filter either by "kde" or "gnome" (depending on preference), or by "editor" (if it does not matter which UI) to discover packages he might be interested in.
\o/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. Cheers -- 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
On Fri, Oct 18, 2019 at 1:48 AM Simon Lees <sflees@suse.de> 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. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/19 4:50 PM, Neal Gompa wrote:
On Fri, Oct 18, 2019 at 1:48 AM Simon Lees <sflees@suse.de> 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
On Fri, Oct 18, 2019 at 3:11 AM Simon Lees <sflees@suse.de> wrote:
On 10/18/19 4:50 PM, Neal Gompa wrote:
On Fri, Oct 18, 2019 at 1:48 AM Simon Lees <sflees@suse.de> 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.
Actually, AppStream has support for console apps, it's just that things like GNOME Software and Plasma Discover ignore them anyway. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. 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. 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. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On 2019-10-19 00:28, Simon Lees wrote:
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.
Well, that exactly was the problem with taking the whole Group: value as categorization; Richard put some examples of these [1], e.g.: Why the hell is a gnome-calculator considered Productivity/Scientific/Math and gedit is Productivity/Text/Editors but most of the other GNOME apps are System/GUI/GNOME? [1] https://lists.opensuse.org/opensuse-factory/2019-10/msg00117.html But when treating each '/'-separated part as tag values, then it would most already look much better: - gnome-calculator = Productivity || Scientific || Math - gedit = Productivity || Text || Editors Obviously, some "neutral" values like "Other" do not make too much sense for a tag. And: nobody on this list ever claimed that the current Group: values are perfect, so any direction we go, there will be some adaption necessary.
[...] it would at this point be better to start from scratch.
... or look a bit outside the openSUSE world: I don't remember if already mentioned this, but I find the way the *CYGWIN installer* presents the packages in categories very useful. A package appears in several categorizations there - I don't know if they call it "tags" there. And even basic packages like the cygwin-dll or coreutils appears there in a reasonable way. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/19/19 6:32 PM, Bernhard Voelker wrote:
On 2019-10-19 00:28, Simon Lees wrote:
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.
Well, that exactly was the problem with taking the whole Group: value as categorization; Richard put some examples of these [1], e.g.:
Why the hell is a gnome-calculator considered Productivity/Scientific/Math and gedit is Productivity/Text/Editors but most of the other GNOME apps are System/GUI/GNOME?
[1] https://lists.opensuse.org/opensuse-factory/2019-10/msg00117.html
But when treating each '/'-separated part as tag values, then it would most already look much better:
- 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. -- 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
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')? 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. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Oct 20, 2019 at 11:02 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
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')?
Or appstream metainfo.xml/appdata.xml files, which cover types of most of the distribution packages, and are already used by KDE/GNOME upstreams for KDE Discover/GNOME Software and our own software-o-o (we don't use rpm metadata there anyway iirc). LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-20 12:35, Stasiek Michalski wrote:
On Sun, Oct 20, 2019 at 11:02 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
b) Where to store?
Or appstream metainfo.xml/appdata.xml files, which cover types of most of the distribution packages, and are already used by KDE/GNOME upstreams for KDE Discover/GNOME Software and our own software-o-o (we don't use rpm metadata there anyway iirc).
You mean in '/usr/share/appdata' ? Hmm, that doesn't seem to be used until now yet: $ find /usr/share/appdata/ -mindepth 1 | wc -l 29 But wouldn't that require the have a package installed before being able to have that information available? I mean what we're searching for is a place a package manager can use to display before or after a package is installed. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Oct 20, 2019 at 1:58 PM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 2019-10-20 12:35, Stasiek Michalski wrote:
On Sun, Oct 20, 2019 at 11:02 AM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
b) Where to store?
Or appstream metainfo.xml/appdata.xml files, which cover types of most of the distribution packages, and are already used by KDE/GNOME upstreams for KDE Discover/GNOME Software and our own software-o-o (we don't use rpm metadata there anyway iirc).
You mean in '/usr/share/appdata' ? Hmm, that doesn't seem to be used until now yet:
$ find /usr/share/appdata/ -mindepth 1 | wc -l 29
Keep in mind /usr/share/metainfo is an accepted alternative (and now the default directory for those files).
But wouldn't that require the have a package installed before being able to have that information available? I mean what we're searching for is a place a package manager can use to display before or after a package is installed.
That metadata is extracted as a packaging step by OBS, and combined into a file as a part of a repository (repodata/***-appdata.xml.gz, repodata/***-appdata-icons.tar.gz), it's then downloaded by zypp and installed with appstream helpers. It's accessible for all the tools on the system, as long as zypp repositories are up to date. Desktop files on the other hand, that would be hard to use before their package is installed, because no such collection happens with them. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2019-10-20 14:05, Stasiek Michalski wrote:
On Sun, Oct 20, 2019 at 1:58 PM, Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 2019-10-20 12:35, Stasiek Michalski wrote: You mean in '/usr/share/appdata' ? Hmm, that doesn't seem to be used until now yet:
$ find /usr/share/appdata/ -mindepth 1 | wc -l 29
Keep in mind /usr/share/metainfo is an accepted alternative (and now the default directory for those files).
Hmm, but this is also "quite empty" (so far): $ find /usr/share/metainfo -mindepth 1 | wc -l 117
But wouldn't that require the have a package installed before being able to have that information available? I mean what we're searching for is a place a package manager can use to display before or after a package is installed.
That metadata is extracted as a packaging step by OBS, and combined into a file as a part of a repository (repodata/***-appdata.xml.gz, repodata/***-appdata-icons.tar.gz), it's then downloaded by zypp and installed with appstream helpers. It's accessible for all the tools on the system, as long as zypp repositories are up to date.
Thanks for the explanation. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday, October 20, 2019 7:26:04 PM CEST Bernhard Voelker wrote:
On 2019-10-20 14:05, Stasiek Michalski wrote:
Keep in mind /usr/share/metainfo is an accepted alternative (and now the default directory for those files).
Hmm, but this is also "quite empty" (so far):
$ find /usr/share/metainfo -mindepth 1 | wc -l 117
These are only your installed applications. $> zgrep '<id>' /var/cache/zypp/raw/*/repodata/*appdata.xml.gz | sort -u | wc -l 1126 Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Monday 2019-10-21 01:04, Simon Lees wrote:
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.
yast may be considered _the_ system software, but it's not _the only_ system management software. I think you need to step back from trying to make the outcome all dependent on yast alone. A hypothetical outcome is that the yast team does not want to implement _the (shunned) view_ in yast, and other contributors do not want to spend their time implementing a view _in (shunned) yast_, then that would then be that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 7:17 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 01:04, Simon Lees wrote:
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.
yast may be considered _the_ system software, but it's not _the only_ system management software. I think you need to step back from trying to make the outcome all dependent on yast alone. A hypothetical outcome is that the yast team does not want to implement _the (shunned) view_ in yast, and other contributors do not want to spend their time implementing a view _in (shunned) yast_, then that would then be that.
Yast is the system manager software that is currently and would be used by most users interested in Yast, most people aren't going to know to look for some other software to browse groups. If Yast is never going to support groups again then personally I don't think the cost that will be bore by the rest of the project maintainers and infrastructure is worth it for the one or two people interested in implementing the feature. There are many many others on and off this list that tend to agree hence the decision over a year ago to drop the use of groups. -- 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
On Monday 2019-10-21 10:52, Simon Lees wrote:
Yast [...] would be used by most users interested in Yast
You don't say!
most people aren't going to know to look for some other software to browse groups.
Why not? Is PackageHub not used? (Someone, excuse me forgetting, also floated the idea of sprucing up software.opensuse.org in the same manner.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 7:27 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 10:52, Simon Lees wrote:
Yast [...] would be used by most users interested in Yast
You don't say!
most people aren't going to know to look for some other software to browse groups.
Why not? Is PackageHub not used? (Someone, excuse me forgetting, also floated the idea of sprucing up software.opensuse.org in the same manner.)
Yes, but as far as I can see it no longer has a group view (or plans are in place to remove it) and sure yeah the idea of software.opensuse.org is also good, if people put in concrete work to get software.o.o and yast working then I happily support some form of groups, as long as packages that really have no need for groups don't have them. But until such a arrangements are made its not worth the cost in review time, rebuild time, release manager time etc. Having said that I think that Ludwig's idea is better so that's what i'm supporting atm should people want to implement it, i'd even be more inclined to support it if yast doesn't get support back because it has a lesser impact on the rest of the project. -- 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
On Mon, Oct 21, 2019 at 11:24 AM, Simon Lees <sflees@suse.de> wrote:
On 10/21/19 7:27 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 10:52, Simon Lees wrote:
Yast [...] would be used by most users interested in Yast
You don't say!
most people aren't going to know to look for some other software to browse groups.
Why not? Is PackageHub not used? (Someone, excuse me forgetting, also floated the idea of sprucing up software.opensuse.org in the same manner.)
Yes, but as far as I can see it no longer has a group view (or plans are in place to remove it) and sure yeah the idea of software.opensuse.org is also good, if people put in concrete work to get software.o.o and yast working then I happily support some form of groups, as long as packages that really have no need for groups don't have them.
Like groups in https://software.opensuse.org/explore ? It wasn't particularly worth it to implement rpm groups there, because it's a service built around obs/appstream first and foremost, not around a particular package format. So if you want software-o-o to support groups in more ways than appstream, we will need to have that implemented as an api in obs. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 21. Oktober 2019, 10:52:48 CET schrieb Simon Lees:
If Yast is never going to support groups again then personally
I'm missing yet another reason for using yast sw_single. Let's spin it the other way around: Given, we have established an improved grouping classification for the available packages, more people *will* find a grouping view in yast useful. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2019-10-28 at 12:20 +0100, Hans-Peter Jansen wrote:
Am Montag, 21. Oktober 2019, 10:52:48 CET schrieb Simon Lees:
If Yast is never going to support groups again then personally
I'm missing yet another reason for using yast sw_single.
Let's spin it the other way around:
Given, we have established an improved grouping classification for the available packages, more people *will* find a grouping view in yast useful.
I think you should consider a hard fact of life - it doesn't matter what a small number of vocal users and/or contributors decide in their own ecochamber, if the actual developers of a tool do not agree, they are under no obligation to impliment any tooling to support any such classification. The YaST team made a concious decision to remove code they knew they no longer wished to support that utilised metadata which a public discussion had (at the time at least) clearly shown to be unnecessary to the Project. Now, the YaST team are quite within their rights to set the barrier as high as they like before they will be convinced to add any new Group- handling functionality. And without tooling making such of such metadata, I think it's an unreasnoble burden on all of our packagers to be expected to follow it in any sort of mandatory manner. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/28/19 3:31 PM, Richard Brown wrote:
On Mon, 2019-10-28 at 12:20 +0100, Hans-Peter Jansen wrote:
Am Montag, 21. Oktober 2019, 10:52:48 CET schrieb Simon Lees:
If Yast is never going to support groups again then personally
I'm missing yet another reason for using yast sw_single.
Let's spin it the other way around:
Given, we have established an improved grouping classification for the available packages, more people *will* find a grouping view in yast useful.
I think you should consider a hard fact of life - it doesn't matter what a small number of vocal users and/or contributors decide in their own ecochamber, if the actual developers of a tool do not agree, they are under no obligation to impliment any tooling to support any such classification.
The YaST team made a concious decision to remove code they knew they no longer wished to support that utilised metadata which a public discussion had (at the time at least) clearly shown to be unnecessary to the Project I just wanted to point out that it was not exactly a YaST Team initiative and that maintainability of the code had nothing to do with it. We removed it because it was reported to us that it was causing more confusion than good.
To be precise and as already pointed in another of the dozen of threads discussing this topic, the YaST Team was requested to remove the functionality via Fate. To be honest, I don't quite remember every detail of the discussion. But the description of the Fate mentioned this: "The preliminary discussion was done on openSUSE Factory list '[opensuse-factory] Killing Group tag in .spec files'." So we finally removed the functionality as requested. We did it via these two pull requests: https://github.com/libyui/libyui-qt-pkg/pull/58 https://github.com/libyui/libyui-ncurses-pkg/pull/27 So we were never exactly excited about removing the functionality, we did it by request and to reduce confusion based on the bad state of the information we were displaying (which is something out of our control). Cheers -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28/10/2019 13:20, Hans-Peter Jansen wrote:
Am Montag, 21. Oktober 2019, 10:52:48 CET schrieb Simon Lees:
If Yast is never going to support groups again then personally
I'm missing yet another reason for using yast sw_single.
Let's spin it the other way around:
Given, we have established an improved grouping classification for the available packages, more people *will* find a grouping view in yast useful.
Pete
It's very simple make a feature request for groups in yast but where it is now I don't know. I've even fulfilled feature requests in the past but I just had a look and I can't find it except for a wiki : https://en.opensuse.org/openSUSE:Openfate Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/30/19 12:05 AM, Dave Plater wrote:
On 28/10/2019 13:20, Hans-Peter Jansen wrote:
Am Montag, 21. Oktober 2019, 10:52:48 CET schrieb Simon Lees:
If Yast is never going to support groups again then personally
I'm missing yet another reason for using yast sw_single.
Let's spin it the other way around:
Given, we have established an improved grouping classification for the available packages, more people *will* find a grouping view in yast useful.
Pete
It's very simple make a feature request for groups in yast but where it is now I don't know. I've even fulfilled feature requests in the past but I just had a look and I can't find it except for a wiki : https://en.opensuse.org/openSUSE:Openfate
Fate has been decommissioned as was mentioned at some time in the past. It didn't really fit with the project well. openSUSE is a project where people for the most part work on what they feel like and no one can tell others what to do. Many developers never really checked fate which means that it mostly ended up with alot of tickets that were never responded to which doesn't give a good impression. Beyond that 95% of fate requests would have been better off in an upstream projects feature request system. So if you want to request a feature in yast i'm guessing that there bugtracker is likely the best place to do it, this is of course no indication that the yast team will implement the feature, whether they do or not is up to them. -- 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
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. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 247165 (AG München) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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
On Monday 2019-10-21 10:19, Ludwig Nussel wrote:
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.
You can't have it both ways. Either people fight over the entry's value, or they don't care. History tells me they staticially won't care.
So I wonder whether to maybe dodge that mine field completely and store tags aka groups outside of packages.
Outside of packages is disconnected metadata, and there seems to be a reservation about such, depending on the interpretation of https://lists.opensuse.org/opensuse-factory/2019-10/msg00115.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 7:54 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 10:19, Ludwig Nussel wrote:
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.
You can't have it both ways. Either people fight over the entry's value, or they don't care. History tells me they staticially won't care.
So I wonder whether to maybe dodge that mine field completely and store tags aka groups outside of packages.
Outside of packages is disconnected metadata, and there seems to be a reservation about such, depending on the interpretation of https://lists.opensuse.org/opensuse-factory/2019-10/msg00115.html
This is just an illustration in the past that people haven't put in the effort to create / keep the data up to date, from looking at the state of our current group system i'm pretty sure the same arguments apply, yes its slightly better because everything has something (if everything having something is even better) but much of the data is inconsistent garbage because people have just picked the easiest path to making a bot happy (and many have complained about it to this list), now that the bot's gone I don't see it being any different unless people who aren't maintainers step up to keep it good (because many maintainers don't care). If people other then maintainers are going to step up and do it in many way's it makes sense for it to be done in a way maintainers don't need to touch it. If a group of non maintainers are willing to keep metadata up to date inside packages then they will be willing to externally as well. If they are not we already as a project decided they shouldn't have to 15 months ago and most haven't changed there mind since. -- 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
Hello, Am Montag, 21. Oktober 2019, 11:40:05 CEST schrieb Simon Lees:
On 10/21/19 7:54 PM, Jan Engelhardt wrote:
On Monday 2019-10-21 10:19, Ludwig Nussel wrote:
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.
You can't have it both ways. Either people fight over the entry's value, or they don't care. History tells me they staticially won't care.
Exactly. That's why I'd atually love to see such a tag fight, because it would indicate that someone cares about these tags ;-)
So I wonder whether to maybe dodge that mine field completely and store tags aka groups outside of packages.
Outside of packages is disconnected metadata, and there seems to be a reservation about such, depending on the interpretation of https://lists.opensuse.org/opensuse-factory/2019-10/msg00115.html
This is just an illustration in the past that people haven't put in the effort to create / keep the data up to date, from looking at the state of our current group system i'm pretty sure the same arguments apply, yes its slightly better because everything has something (if everything having something is even better) but much of the data is inconsistent garbage because people have just picked the easiest path to making a bot happy (and many have complained about it to this list), now that the bot's gone I don't see it being any different unless people who aren't maintainers step up to keep it good
I have no idea how many make-the-bot-happy groups we have in our packages, but (after a quick check on several of the packages I have installed) I'd guess that at least 95% of our packages have a sane group. (Of course it's easier and more entertaining to point out some packages with a "wrong" group than listing all the packages with a correct or good-enough group.) For comparison - we have 1126 RPMs with appdata (number from Stefan Brüns somewhere else in this discussion). Compare that to 12455 source packages in openSUSE:Factory, and you'll get that only 9% of our source packages have appdata. For the resulting RPMs, the number is even worse because a source package can produce multiple RPMs (see texlive-spec-* for some extreme variants ;-)
If people other then maintainers are going to step up and do it in many way's it makes sense for it to be done in a way maintainers don't need to touch it.
I disagree on the idea of moving the group/tags outside of the spec file. If it is in the spec file, then lots of maintainers will "accidently" add or adjusts the group/tags because it's easy and not much work. If it's somewhere external, that's quite some (too much?) work ("why should I jump through another loop?"), and we'll for sure get the result that "package maintainers don't care about groups/tags". Even if a maintainer doesn't care, he/she'll probably accept a SR that updates the group/tags - and if it's only because declining it might result in getting it reopened etc. which means more work ;-) Therefore I'd really prefer to keep the group/tags/whatever in the spec file. We have a somewhat similar situation with the openSUSE infrastructure where information about each VM is split up across multiple places (pages in our internal wiki and in the salt pillar/id/ files). In practise, only the salt files get updated (because that's what is used in production) while the wiki pages are terribly outdated. I'm currently working on moving the content of the VM-specific wiki pages to the salt pillar/id/ files. Besides having all information about a VM in one place, it has the big advantage that someone who edits the salt file most probably keeps the whole file up-to-date. The chance that someone updates the wiki page is much smaller. This change is quite new and still has to prove itsself as working, but OTOH we already know that splitting information across multiple places lead to terribly outdated information in our internal wiki - simply because people forget to update all places, or are too lazy to do it.
If a group of non maintainers are willing to keep metadata up to date inside packages then they will be willing to externally as well.
Hmmm, meine Glaskugel ist schon wieder in der Spülmaschine.... Hallo Volker - wo gibt es solche Glaskugeln?
They'll have much less work if the metadata is kept in the spec file, because lots of maintainers will "accidently" maintain it, even if they don't care too much. Regards, Christian Boltz -- trotz Spülmaschine, 100% Trefferquote :-)) [> Volker Kroll und Herbert Schrader in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/22/19 9:50 AM, Christian Boltz wrote:
Hello,
Am Montag, 21. Oktober 2019, 11:40:05 CEST schrieb Simon Lees:
If people other then maintainers are going to step up and do it in many way's it makes sense for it to be done in a way maintainers don't need to touch it.
I disagree on the idea of moving the group/tags outside of the spec file.
If it is in the spec file, then lots of maintainers will "accidently" add or adjusts the group/tags because it's easy and not much work.
Here i'll disagree, we have years of experience suggesting people probably wont hence the mess we have now. -- 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
Am 22.10.19 um 02:14 schrieb Simon Lees:
Here i'll disagree, we have years of experience suggesting people probably wont hence the mess we have now.
IMNSHO this is the result of the crazy rpmlint check (which was the last thing that was removed in the whole thing, long after some packaging committee decided that groups must go, and probably only to actually allow the groups to be removed), which forced people to choose totally stupid and non-fitting groups, and in consequence they decided "fsck it, I'll no longer care". If the first thing of this whole ordeal would have been "let's remove the stupid rpmlint check" and then encourage people to actually use matching groups -- I'm pretty sure the mess would be quite a bit smaller than what we have now. But the "YOU MUST OBEY THE GODLY BOTS" fraction here is much too strong, this is why this all is nowadays the total opposite of "a lot of fun...", and why people no longer care. Just add a stupid workaround so that the bot is happy. For the record: I not only do no longer really care about groups, I also no longer really care if "my" packages are being included in openSUSE, as long as I can easily build them on the build service. Congratulations, you have achieved your goal. Less packages means less work. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 10:19 AM, Ludwig Nussel wrote:
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.
I like the idea - but it's quite some work. But if we go there, we can just close this discussion because we don't need to define anything as every group will be overwritten / inserted on product build and we can fade out groups from spec files slowly. And the solution would have to be easy to pickup for derived products (not only the obvious SLE products, but openSUSE spins as well). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2019-10-21 10:19, Ludwig Nussel wrote:
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.
having such a discussion over a package's disputed tags with its maintainer seems preferable to having a disputable change sneaking into a dataset that the package maintainer either does not observe, or worse, cannot exert any control. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 20.10.19 um 06:08 schrieb Simon Lees:
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.
These can easily get an additional tag or whatever mark to hide them from search results by default and just include them if "really show me everything" is checked. By the way -- *-lang packages are hopefully only "Recommends:"-ed anyway and since alomost everyone nowaday uses "--no-recommends" for daily business anyway, it would be actually helpful to have a tag "language package" on them, maybe even with the actual language they contain as an additional tag, so that they can be found and installed manually. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/19 7:35 PM, Stefan Seyfried wrote:
Am 20.10.19 um 06:08 schrieb Simon Lees:
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.
These can easily get an additional tag or whatever mark to hide them from search results by default and just include them if "really show me everything" is checked.
By the way -- *-lang packages are hopefully only "Recommends:"-ed anyway and since alomost everyone nowaday uses "--no-recommends" for daily business anyway, it would be actually helpful to have a tag "language package" on them, maybe even with the actual language they contain as an additional tag, so that they can be found and installed manually.
Maybe everyone in certain parts of the community are using --no-recommends but pretty much everyone I talk to is not. Longer term language packages really need fixing properly, that means that in yast you should configure the languages that you want and then using supplements all the right packages for your language get installed. A similar better solution to the problem you describe here is a yast filter that lists all the packages that are recommended for your system but not installed then you could search that list for *-lang and get everything you care about or for any other package where you might actually want the recommended packages for whatever reason. -- 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
* Simon Lees <sflees@suse.de> [10-20-19 19:19]:
On 10/20/19 7:35 PM, Stefan Seyfried wrote:
Am 20.10.19 um 06:08 schrieb Simon Lees:
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.
These can easily get an additional tag or whatever mark to hide them from search results by default and just include them if "really show me everything" is checked.
By the way -- *-lang packages are hopefully only "Recommends:"-ed anyway and since alomost everyone nowaday uses "--no-recommends" for daily business anyway, it would be actually helpful to have a tag "language package" on them, maybe even with the actual language they contain as an additional tag, so that they can be found and installed manually.
Maybe everyone in certain parts of the community are using --no-recommends but pretty much everyone I talk to is not.
I use "--no-recommends"
Longer term language packages really need fixing properly, that means that in yast you should configure the languages that you want and then using supplements all the right packages for your language get installed.
A similar better solution to the problem you describe here is a yast filter that lists all the packages that are recommended for your system but not installed then you could search that list for *-lang and get everything you care about or for any other package where you might actually want the recommended packages for whatever reason.
and the first thing on a new system: zypper -v rm *-lang -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 21.10.19 um 01:18 schrieb Simon Lees:
A similar better solution to the problem you describe here is a yast filter that lists all the packages that are recommended for your system but not installed then you could search that list for *-lang and get
...and miss MozillaFirefox-translations-common. Besides, I know really noone who is using yast2 to install software (maybe by accident when you call a yast module that decides that something needs to be installed and then uses yast2-packager to install it). I'm more of an enterprise linux guy though, and people here do not like the surprises that the omission of "solver.onlyRequires = true" brings. With tumbleweed on my home machine, the daily size increase of installing recommends is just not desired by most. The few people I know who install recommends, also do regular re-installs of their machines. I just reinstall when moving to a new hardware architecture, which happens only maybe once per decade, if at all. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 5:28 PM, Stefan Seyfried wrote:
Am 21.10.19 um 01:18 schrieb Simon Lees:
A similar better solution to the problem you describe here is a yast filter that lists all the packages that are recommended for your system but not installed then you could search that list for *-lang and get
...and miss MozillaFirefox-translations-common.
Besides, I know really noone who is using yast2 to install software (maybe by accident when you call a yast module that decides that something needs to be installed and then uses yast2-packager to install it).
Hi I'd like to introduce you to Simon, Simon regularly uses yast to install software, especially when he doesn't know the exact package name. And now you know someone who does, I know many others who do as well. -- 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
Stefan Seyfried schrieb:
Am 20.10.19 um 06:08 schrieb Simon Lees:
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.
These can easily get an additional tag or whatever mark to hide them from search results by default and just include them if "really show me everything" is checked.
By the way -- *-lang packages are hopefully only "Recommends:"-ed anyway and since alomost everyone nowaday uses "--no-recommends" for daily business anyway, it would be actually helpful to have a tag "language package" on them, maybe even with the actual language they contain as an additional tag, so that they can be found and installed manually.
https://build.opensuse.org/request/show/737162 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 247165 (AG München) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 19.10.19 um 00:28 schrieb Simon Lees:
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"
For you. Not for me. I might want to search for the minimal needed system components via a group search. So what you call "noise" would be easy to filter out by the searching tool by just ignoring everyhting "basesystem" when not explicitly being asked for "show all search results, even trivial dependencies" or similar. But not by omitting info in the first place.
It does sound simple until you look at the fact that what we have for current groups is a bit of a mess.
Nobody here really says that the current grouping is the best thing since sliced bread. That's exactly what Jan's proposal is about IMVHO: specifying a better way to tag/group packages.
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.
Jan is actively re-grouping packages for quite some time now, and I have not much reason to assume that he is going to stop doing this once we have agreed on a better set of tags/groups to use. So this will sort itself out. Berny's suggestion of "just read 'Base/System' as two tags: "base" "system" has the added benefit that you actually get an indication that "this package is 'legacy', not converted to the new tag system" (by just checking if groups field is '/'-separated and not space-separated), so the frontend could indeed rate those package differently on the search results.
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.
That's your suggestion, I think all packages should be able to be found via a tag/group search, not only a very small percentage. (Disclaimer: I have no idea what categories are permitted for desktop files, and who decides this. If it is someone at fd.o, I'm against it ;-))
So while that approach may sound straight forward it isn't really. It is, IMHO. -- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/19/19 7:58 PM, Stefan Seyfried wrote:
Am 19.10.19 um 00:28 schrieb Simon Lees:
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"
For you. Not for me. I might want to search for the minimal needed system components via a group search.
So what you call "noise" would be easy to filter out by the searching tool by just ignoring everyhting "basesystem" when not explicitly being asked for "show all search results, even trivial dependencies" or similar. But not by omitting info in the first place.
Yep but there is still no need for you to ever install any of the system libraries that are currently in a "basesystem" group so they for example just add "noise" to that category. I'm not arguing that no base system components should have tags i'm just arguing that in the current group system there are many things that have tags that don't really make sense. Extending that things like systemd and dbus probably also don't need tags because you can't uninstall them.
It does sound simple until you look at the fact that what we have for current groups is a bit of a mess.
Nobody here really says that the current grouping is the best thing since sliced bread. That's exactly what Jan's proposal is about IMVHO: specifying a better way to tag/group packages.
As is my proposal
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.
That's your suggestion, I think all packages should be able to be found via a tag/group search, not only a very small percentage. (Disclaimer: I have no idea what categories are permitted for desktop files, and who decides this. If it is someone at fd.o, I'm against it ;-))
It is decided by the collaboration of developers from various desktops and distro's but the current version of the specification is hosted on the fd.o website, but there is scope along side the specification for us to extend it to cover any new categories that we need. -- 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
Am 20.10.19 um 06:34 schrieb Simon Lees:
sense. Extending that things like systemd and dbus probably also don't need tags because you can't uninstall them.
Thorsten is probably not happy to hear that! ;-) Of course they also need tags. Even if you won't use them. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/20/19 7:38 PM, Stefan Seyfried wrote:
Am 20.10.19 um 06:34 schrieb Simon Lees:
sense. Extending that things like systemd and dbus probably also don't need tags because you can't uninstall them.
Thorsten is probably not happy to hear that! ;-)
Of course they also need tags. Even if you won't use them.
As the maintainer of dbus I will respectfully disgaree, it is not possible to have an openSUSE system where you can browse groups / tags and not have dbus installed, therefore listing it is a waste of anyone who wants to use groups time (including myself) as they then have to scroll past an item they can't do anything with. -- 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
Am 21.10.19 um 01:09 schrieb Simon Lees:
As the maintainer of dbus I will respectfully disgaree, it is not possible to have an openSUSE system where you can browse groups / tags and not have dbus installed, therefore listing it is a waste of anyone who wants to use groups time (including myself) as they then have to scroll past an item they can't do anything with.
I have containers with rpm / zypper but no dbus inside. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/21/19 5:30 PM, Stefan Seyfried wrote:
Am 21.10.19 um 01:09 schrieb Simon Lees:
As the maintainer of dbus I will respectfully disgaree, it is not possible to have an openSUSE system where you can browse groups / tags and not have dbus installed, therefore listing it is a waste of anyone who wants to use groups time (including myself) as they then have to scroll past an item they can't do anything with.
I have containers with rpm / zypper but no dbus inside. Yes and zypper / rpm have never had the ability to search groups
-- 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
On 10/21/19 1:09 AM, Simon Lees wrote:
As the maintainer of dbus I will respectfully disgaree, it is not possible to have an openSUSE system where you can browse groups / tags and not have dbus installed, therefore listing it is a waste of anyone who wants to use groups time (including myself) as they then have to scroll past an item they can't do anything with.
E.g. there is the 'zypper search -u' (--not-installed-only) option, so tags support could end up there as e.g 'zypper se -u --tags editor' to find not-installed editors. I guess others like yast could have something similar. Again the analogy to the Cygwin installer ... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2019-10-19 00:28, Simon Lees wrote:
A big part of my proposal is to only provide group info for things that make sense to be found with group info
Ah but that the pedantic reader might think "how do you determine what does and what does not make sense to be searched", that inherently is asking for an opinion again.
which means libraries and other core dependencies that people will have installed anyway shouldn't really have groups because it will just add "noise"
I would like to come back to that. In an earlier posting, if I remember it right, you pointed to certain packages being special/specific enough that one would only target them by name, something like libblah-devel, hence it would not need a classification. But the universes of texlive, CPAN, Haskell, and other "repackagings" in openSUSE is quite large, and if I am not well versed in the use of said programming language, I might start going for an unspecific search there. Looking for something to spruce up PDF presentations? Well texlive-beamer might be that if it had that presentation tag. Need a HTTP client in Perl, and don't like LWP? Try tags perl http - if the packages had them.
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. [...] 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.
But just a "bit of a mess". Iff groups were a veritable mess and not good enough a "starting point", then something like PackageHub would not have worked with the RPM Group: field as it did, would it; instead it would have had to use the disconnected yast-Package-Group dataset or something.
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.
That's an issue of the single-valuedness, not so much the selectable topic names. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/19/19 7:59 PM, Jan Engelhardt wrote:
On Saturday 2019-10-19 00:28, Simon Lees wrote:
A big part of my proposal is to only provide group info for things that make sense to be found with group info
Ah but that the pedantic reader might think "how do you determine what does and what does not make sense to be searched", that inherently is asking for an opinion again.
Well I think there will always be a grey area, there are some things where its obviously useful others where they are clearly not useful and then there is the bit in between. Generally in openSUSE for other such "grey area's" we leave it up to the maintainers discretion.
which means libraries and other core dependencies that people will have installed anyway shouldn't really have groups because it will just add "noise"
I would like to come back to that. In an earlier posting, if I remember it right, you pointed to certain packages being special/specific enough that one would only target them by name, something like libblah-devel, hence it would not need a classification.
But the universes of texlive, CPAN, Haskell, and other "repackagings" in openSUSE is quite large, and if I am not well versed in the use of said programming language, I might start going for an unspecific search there. Looking for something to spruce up PDF presentations? Well texlive-beamer might be that if it had that presentation tag. Need a HTTP client in Perl, and don't like LWP? Try tags perl http - if the packages had them.
Well as a developer this perl example doesn't really hold for me. If I am looking for something like that then the things I care about are the API, documentation etc and I won't be able to tell that from Yast so i'd be starting my search from google instead.
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. [...] 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.
But just a "bit of a mess". Iff groups were a veritable mess and not good enough a "starting point", then something like PackageHub would not have worked with the RPM Group: field as it did, would it; instead it would have had to use the disconnected yast-Package-Group dataset or something.
Package hub has a more limited set of packages then openSUSE which likely makes it less of an issue.
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.
That's an issue of the single-valuedness, not so much the selectable topic names.
Yes but given the single-valuedness of the old system it makes using it as a starting point more of an issue. Although most packages using desktop files are single valued yet don't have these issues. -- 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
On Friday 2019-10-18 07:48, 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.
I find that 1799 (noarch|x86_64).rpm files carry a /usr/share/applications/*.desktop file; the ARCHIVES.gz lists 39095 such rpms overall, which puts the coverage of your suggestion to 4%, which is about the same as Richard's proposal of using AppData XML files instead. That would also still leave Stasiek's point open that you would have to contribute to every upstream package to fix a blatant miscategorization. I remember there was something like %suse_update_desktop_files to take care of it locally, but that macro seems to have gone too.
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. [...] 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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2019-10-18 at 10:10 +0200, Jan Engelhardt wrote:
I remember there was something like %suse_update_desktop_files to take care of it locally, but that macro seems to have gone too.
It's %suse_update_desktop_file (singular) and still exists as part of the update-desktop-files (plural) package. Cheers, Dominique
Am Freitag, 18. Oktober 2019, 10:29:13 CEST schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-18 at 10:10 +0200, Jan Engelhardt wrote:
I remember there was something like %suse_update_desktop_files to take care of it locally, but that macro seems to have gone too.
It's %suse_update_desktop_file (singular) and still exists as part of the update-desktop-files (plural) package.
and requires yet another build dependency, just for categorization. A more pragmatic approach would be * create a super-set of desktop file categories and other group tags * add a group line to the spec with spec-cleaner, if there's none already, and a desktop file is included in that package We could even separate group tags by semicolon for uniformity reasons. A further step could be an automatic transformation of path like group lines to tags (where a final semicolon would also help distinguishing from already transformed tags). Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/18/19 10:23 PM, Hans-Peter Jansen wrote:
Am Freitag, 18. Oktober 2019, 10:29:13 CEST schrieb Dominique Leuenberger / DimStar:
On Fri, 2019-10-18 at 10:10 +0200, Jan Engelhardt wrote:
I remember there was something like %suse_update_desktop_files to take care of it locally, but that macro seems to have gone too.
It's %suse_update_desktop_file (singular) and still exists as part of the update-desktop-files (plural) package.
and requires yet another build dependency, just for categorization.
If it was used everywhere it could be added to the project configthat package really only depends on other things we already need for every build.
A more pragmatic approach would be * create a super-set of desktop file categories and other group tags * add a group line to the spec with spec-cleaner, if there's none already, and a desktop file is included in that package
This wouldn't work in many cases, spec-cleaner can only read .spec files which means in some cases it could get it from looking at the "%suse_update_desktop_file" but in many cases upstream use the same category as us or we source the whole spec file so its correct or sometimes we change the category in a patch in all of those cases spec-cleaner would have no idea of the category so it needs to be worked out post install phase to be really useful. -- 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
On 10/18/19 6:40 PM, Jan Engelhardt wrote:
On Friday 2019-10-18 07:48, 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.
I find that 1799 (noarch|x86_64).rpm files carry a /usr/share/applications/*.desktop file; the ARCHIVES.gz lists 39095 such rpms overall, which puts the coverage of your suggestion to 4%, which is about the same as Richard's proposal of using AppData XML files instead.
Taking a very conservative view here maybe this also means that if only 4% of packages ship such data and we know all desktop apps do, if you left a very conservative 4% for cli apps or select other things that people may search for via groups it means that currently 92% of packages ship group information that is basically useless to users such as shared libs etc. Texlive probably skews that alot but that probably doesn't need a group really because searching "texlive" will give you all the results you need. -- 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
participants (17)
-
Ancor Gonzalez Sosa -
Bernhard Voelker -
Christian Boltz -
Dave Plater -
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Jan Engelhardt -
Ludwig Nussel -
Michal Suchánek -
Neal Gompa -
Patrick Shanahan -
Richard Brown -
Simon Lees -
Stasiek Michalski -
Stefan Brüns -
Stefan Seyfried -
Stephan Kulow