[Mageia-dev] RPM groups policy

[Pierre-Malo Deniélou]

Le 27/09/12 10:04,Colin Guthrie nous adresse ces quelques mots :
> Just ran into my first practical problem and would like your feedback.

I'm guessing your email is just the first of a long list :-).
The new RPM group will indeed cause some head scratching for many packages.

> PulseAudio packages used to just be in "Sound" group, but now I have to
> sub-categorise them as Sound/*. This is fine and I put everything in the
> Sound/Mixer category for now as this is one of the tasks PA does, mix
> your audio, but I get the feeling this group was more designed to
> represent graphical mixer UIs rather than infrastructure level stuff.

RPM groups are for users, not necessarily technical users (technical
users already know which packages interest them).
So the main advice to find the category of a given package is:

Where would it make sense for a user browsing through a list to find it?

For PulseAudio, Sound/Mixer is fine.

> Should there be a group that represents this better? e.g.
> 
> Sound/Plumbing
> System/Sound
> Plumbing/Sound

Or Sound/PulseAudio ... :-P

That's the Suse approach, but it does not work. It only multiplies the
groups, with 3 or 4 subdivision depths (Amusements/Games/Strategy/Turn
Based ...), with some groups only having a handful of packages. Many of
the subdivisions make sense from a packaging point of view, but from a
user point of view it makes browsing too precise. I personally think
that groups are meant for the exploration by people who don't know what
they are looking for.

> Or perhaps PA should just go in System/Base?

No. It only drowns it in the crowd of completely unrelated packages.

> (I use the term Plumbing as this is quite common these days as an off
> shoot perhaps from the Linux Plumbers Conference where the various
> infrastructural bits of linux are discussed).
> 
> Thoughts?

No RPM group classification is perfect. There will always be a package
that does not fit the classification. So we should stick to the "best
guess" strategy for now.

The new RPM group policy is not completely fixed, but I propose that
everyone tries to stick with it until Beta 1, at which point we can
review it and amend the most obvious problems.

Cheers,
-- 
Malo