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:
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?
Generally translations are stored in the binary alongside the original strings or in a separate file that ships with the binary that it loads and uses rpm doesn't really have support for handling translations in its metadata in any form and if it did our the software our translation team use isn't set up to search across obs to find translation strings in all the spec files. Where as if we do groups externally its easy to intergrate into our existing translation software.
But we can have data on all binaries collected so cnf can do its job. Can't we have package tags collected in the same way so that software that works with individual packages can use the pacakge metadata and software that works with the repositories and uninstalled packages the repository metadata? Surely that will make translation possible as well.
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.
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.
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)?
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. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org