rpm groups and fedora: a modest proposal
brads at redhat.com
Wed May 26 14:49:39 UTC 2004
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.
More information about the devel