Am Freitag, 1. November 2019, 01:12:55 CET schrieb Simon Lees:
On 11/1/19 12:11 AM, Hans-Peter Jansen wrote:
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.
I'm inclined to disagree.
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.
Well, managing groups outside of specs, I can see a slight improvement in translation handling, but the comes with an even higher prize of disjoint group management. What technical reasons hinders the translation of a collection of tags exactly?
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.
Again, I think, you devaluate the existing system. It is lacking, but the existing system isn't in a such a bad shape, that some of you want to color it. As shown in this discussion, more than 90% of group specs are fine.
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".
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... BTW, I really dream from a more specific/versatile search in OBS and grouping tags could help here as well.
[...]
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.
Don't take me wrong here, patterns are fine as such! They just don't show the full picture. With an improved grouping, we might even be able to reduce the sheer number of them, making them even more useful..
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.
Since we all suffer from limited resources, this is also the most critical argument for a pragmatic approach here.
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)? How will this being made available in the different areas, where it's needed? (YaST, OBS, software.o.o, ...) A typical case: I realize, that one of my packages is missing in a group. A single commit later, I'm done. With the external approach, many more hops needs to be taken, before a package is classified correctly. The most outstanding argument against grouping, as it exists today, is the single valuedness.. Why don't we combine the proposals to centralize the management of tags, easing the work of the translation "department", providing an interface for creating proposals, and assigning these standardized tags in the spec. Translation is a none issue, it doesn't need any rpm bending, but the web interface, which can be bridged with some wiki list meanwhile. I've created a lot of packages myself (approx. approaching 3 digit numbers), and just copying a line in a spec file is *way* more convenient than anything else (external or even just using an additional file in the package). The reason, why Ludwig suggested the external approach was mainly avoiding the "fight" over tags. But Christian rightfully turned out, that this would be a good thing, because it would show, that people care, and I agree here. We need to tie those loose ends together, that makes groups great again, with minimal load to the involved people, because we need to accept, that we have very limited resources to do so, only. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org