On 11/4/19 2:12 AM, Michal Suchánek wrote:
On Sat, Nov 02, 2019 at 10:41:37AM +1030, Simon Lees wrote:
On 11/1/19 11:18 PM, Hans-Peter Jansen wrote:
Am Freitag, 1. November 2019, 01:12:55 CET schrieb Simon Lees:
On 11/1/19 12:11 AM, Hans-Peter Jansen wrote:
In the Pro-Grouping-Tag camp, we tried to find an easy to provide solution, that actually would *add* value to the distribution as a whole, and would set it apart for others *without* *much* *fuzz*.
Well I am also in the "Pro-Grouping-Tag camp" I just don't think doing it in spec files is the best way.
The thing, that matters most here is, the existing system can be easily transformed into something hugely useful. Pushing it outside the packages itself creates a load to already overloaded package maintainers. Combined with explicitly and implicitly expressed general desinterest is the reason for me claiming this approach being "doomed to die".
It has become quite clear that most package maintainers aren't really interested in maintaining groups, having it externally means that more people who care about groups can help without having to learn about packaging.
The size of the out-of-package group index we have now tells quite different story as has been pointed out several times already. Will removing the group information from the spec files magically create hosts of people who do care about external metadata?
I don't think so.
Still maybe it will be more then the limited number of packagers interested in it at the moment, making things easier for others is only going to help and the reality is if there isn't enough people to maintain the groups externally there likely isn't enough to maintain it internally which is why this discussion started 15 months back.
With a tag based grouping scheme in the rpm spec, rpmlint could *recommend* adding tags to the packager, if missing or in the old format. A tag based grouping would allow YaST to restore the group view in a much more useful way, that actually would help our users, especially the *new* ones, to find their way though the overwhelming number of packages.
The proposed external solution would also allow yast to display groups in this equally useful way. However the decision was made over a year back that with the state groups were in then the group view was actually more harmful confusing to users because often groups were missing programs that someone would reasonably expect to be there. Not to mention the significant number of packages such as system libraries that users should never need to install on there own.
Well, the value of grouping tags reaches way beyond simple installation tasks. In fact, I often want to lookup libraries for dependency resolution, where such a library tag could improve lookups, because one never no, is this library called libsomething or something, or something totally different.. All of us were snared by that trap already...
Well the whole reason we have a package management system is so that general users don't need to deal with manual dependency resolution, for developers stuff like `rpm -q --whatprovides "pkgconfig(dbus-1)"` is a far quicker and easier way then searching via groups.
Only if you know the name of the package. If you want a library that does something and want to pick one of the available options groups are useful.
As I said in an earlier discussion if I want to pick a development library I need to know stuff about API's, documentation etc which makes google a far better starting place then group tags.
This decision on the other hand will lead to a less approachable product in the end. It "sells" under a fair value already, because many non mainstream abilities are hard to find without resorting to external resources.
Well the plan would be to store the meta data in external resources because it makes more technical sense there due to the limitation of spec files, but then intergrate the display of the data into the right parts of openSUSE such as yast and software.opensuse.org
Okay Simon, thanks for the valuable discussion.
Let's get a bit more technical. Where is this data supposed to be stored? What's the proposed workflow for an average packager (that cares)?
This will be for those implementing the solution to decide.
So it'a all vaporware. You trade something not perfect for something completely non-existent. That does not sound like a good tradeoff to me.
Well given that none of openSUSE's integrated tools currently have integration with the old group system id say that its equally vaporware in its current state. -- 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