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
