Am Sonntag, 3. November 2019, 16:42:29 CET schrieb Michal Suchánek:
On Sat, Nov 02, 2019 at 10:41:37AM +1030, Simon Lees wrote:
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.
Again, as repeated a couple of times, packager didn't care, because: * the single tree value scheme was lacking * rpmlint enforcements suck rocks (ask Seife!) * the former issue excellerates, if it's based on non essential reasons (technical or other)
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.
And extends to queries, where you don't know *anything* about the lib{,s existence} beforehand. (Does this lib exist, or do I need to build myself?) I claim, that simple tag based group information in specs, integrated into OBS advanced search, would raise their value massively (and provides a further reason for packagers to fill this simple field adequately). OTOH, relocating/transforming them into something external, non-existing by now and in the near future, it *will never fly*. Sorry, but it's that simple, Simon. Jan's et.al. approach is coming from the practicability side of things, while the Board tries to establish an artificial top down approach, that depend on a lot of voluntary work, but nobody indicated any interest to do that. Doomed... It *will* work the other way around: Provide a simple, yet flexible group tag scheme (DONE). *Suggest* filling the field with rpmlint (TBD, easy). Explain packagers, why it is *advantageous* to fill this field (even if those services doesn't exist, yet) (TBD, easy). Everything else will follow, because the basics are sound. This is a cooperative approach, that has a chance to work, with a low impact on the workflow of packagers. I don't see translations of those tags as something critical, I would even leave that to later generations, but they're possible, of course. Groups, if they survive this dispute, will keep to be a "professional tool". Translations don't *add* much value here, it might even decrease their usefulness, if queries doesn't look up the English terms as well! They have cosmetic value at most. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org