On 11/1/19 12:11 AM, Hans-Peter Jansen wrote:
Am Mittwoch, 30. Oktober 2019, 06:06:39 CET schrieb Simon Lees:
Hi All,
It likely comes as no surprise to anyone one that the groups in spec file issue was raised with the board (one of these was on a public list). In this specific email we are acting in our role of "helping resolve conflicts" complaints were also made directly about the behavior of certain individuals (again including on this list). The board has chosen to deal with these issues in private as is our general approach to such issues.
Firstly the board generally agrees that in the following thread [1] there was a plan and general agreement to follow it for the removal of groups if certain other issues were resolved. As such we believe they acted with good intentions when starting to remove group support from various places such as Yast, rpmlint and spec cleaner.
The board decided to wait until the discussion on new proposals settled down, before going forward with the issue, at the time we had the discussion we believed this to be the case.
Of all the proposals discussed the board agreed that the one submitted by Ludwig [2], to move groups into the repository meta data is technically the best solution and the one most broadly supported by contributors. As such we welcome any contributions from the community towards getting this working and integrated into tooling where it makes sense such as Yast and software.opensuse.org
Given that our core tooling no longer displays groups and that the board has a copy of all the existing groups that can be used as a starting point for the new system the board has decided that including groups in spec files should now be optional with the final decision resting with the maintainer as some maintainers may still use there spec files in distro's that still support groups although we believe most packages going into factory wont.
We realize that this decision will not make everyone happy but hopefully it eventually leads to better group support in the future.
1. https://lists.opensuse.org/opensuse-factory/2018-05/msg00460.html 2. https://lists.opensuse.org/opensuse-factory/2019-10/msg00263.html
Let me translate this to colloquial language:
The people, that didn't care a fuzz about grouping packages and even tried to create sneaky precedents to get rid of them, decide to bury the whole topic in the backyard, where those, that care, won't dig it up again.
It's a semi smart way to phase out an uncomfortable discussion (to put it politely).
An external management of package grouping is doomed to die, as the amount of work will surpass it's usefulness.
Many consider that the state the internal management of groups would equally indicate that it had failed.
Well, in fact, if you reread the answers to Ludwig's proposal, you find mostly refusals or warnings to take that route.
Between them there are suggestions from people who are either heavily involved or that have been heavily involved in release management agreeing that it would be a better solution for them to be external, including reasons that it would be technically Superior such as translations. Beyond that we have years of evidence that leaving it to maintainers, many of who don't strongly care has lead to a big mess.
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.
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.
I remember times in the past, where I browsed through these groups in YaST to explore the hidden features, that were all in this *magical* box. And now, that we talk about, the existing group view is still great. The "special" groups are especially nice.
I equally remember the feature being useful at some pont.
What you're trying to enforce is something we mostly have already: patterns, but they depend on preferences of a few maintainers. The group view entries could be extended to trees from the tags, that could lead to a nice way to navigate though *all* packages in a smart way, while keeping the grouping where it belongs, in the hand of packagers (that care). I'm sure, that most packagers will welcome a polite notice from rpmlint, if it helps users to locate their packages.
As someone who maintains a number of patterns, I see them as very different things, for example we no longer have patterns for things like media players or text editors, because most users only want one installed. A pattern that installs 10 text editors is not useful where as a group view that shows text editors is. Having said that I am always after suggestions on how to improve patterns so if you have them let me know. As such I'd also like to see groups implemented in a way that is useful for users but currently there are also many other things i'd like to see and they are much higher on my todo list.
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 -- 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