You make some very compelling points, but I still disagree with this:
see thats sort of the point... grouping information is NOT useful in
a
standalone situation. Group information is ONLY useful when we are
talking about multiple packages. Sort of the definition of a group of
packages. If people are building standlone packages..i see no reason
for them to impress on the people 'grouping' packages their
pre-concieved ideas. The package description and summary should be
more than enough to 'hint' to people who are 'grouping' stand alone
packages into groups that makes intuitive sense to them.
Ok, so I've installed foo.rpm (which we'll assume is a game) and I
figured out what it was not by looking at Groups, but by looking at the
description in the headers, on the website etc. Sure enough that's how I
do it and I think you're correct in asserting that that's how most
others do it as well.
But now it's installed. So suppose I'm cleaning up my system and I run
system-config-packages and go looking through the games to see what I'm
not using anymore. Or suppose I'm just a user on the system and I'm
using some other tool just to see what all is installed. I would expect
foo to show up under games, but if it was just downloaded from the web
and the various *.xml files are the only sources for grouping
information it's not. Best-case scenario it goes into an ugly "Other"
category. Worst-case it's ignored.
So there is a need for grouping info even for "standalone" packages
because once they are installed they become part of a group of packages,
effective management of which is very important. So I still say the best
solution is to use *.xml but allow the tools to fall back on the rpm's
headers if that fails.
--Brad