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
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
What technical reasons hinders the translation of a collection of tags
Beyond that we have years of evidence that leaving it
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.
Pro-Grouping-Tag camp, we tried to find an easy to provide
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
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
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.
on the other hand will lead to a less approachable product
the end. It "sells" under a fair value already, because many non
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
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.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org