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
