Opening the Group-tag debate

Hi,

I realised (again) that there is a real need for better categorizing 
packages into Groups. Now, there are a few options, more involved parties 
and possibly even more strong opinions.

The debate preferably should be between all interested parties (ie. 
rpm-devel, all 3rd party repos, mandrake, PLD, SuSE, Red Hat). So this is 
not going to be easy.

Therefor I'd like to start here with a discussion that hopefully results 
in some sort of whitepaper laying down what would be the scale of options 
and a recommendation. Which we then can take to all the parties to 
discuss.

Here's a small list of thoughts about the very issue:

 + Extend the current list of Groups

   Take /usr/share/doc/rpm-*/GROUPS, add the ones Red Hat added with 
   recent packages (eg. tomcat-test), add some widely used ones (like 
   Applications/CPAN) and then look what packages would need a much better 
   category then they are now part of. Instead of directly suggesting 
   names, I prefer to described what it is for. We can later map it into 
   the existing namespace.

	eg.	a category for network debugging tools
		a category for educational software
		a category for plugins/themes

   The same effort could also deprecate some of the badly used Groups. Or 
   split existing Groups that are now overly used. (synaptic shows that 
   rather well)


 + Allow for multiple categories

   Either by having this feature into RPM (low chance) or by working 
   around it using metadata (see Morten's email). I think Mandrake is 
   doing this already, so a working implementation (albeit dated) exists.


If people from other packaging groups or distributions are looking, please 
join this debate instead of implementing something new. I rather now about 
existing other implementations so that we can adapt to that and converge 
to a single namespace in the long run.

Also, keep the replies to the point (or take things in private when having 
subdiscussions), I don't want another brainstorm session that will 
end up dividing us even more...

--   dag wieers,  [email protected],  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]