One of the vestigial tags in the rpm format is "Group". Long ago, this was used by the installer to sort out packages by function, to make it easier to choose what you wanted installed. But recent installers don't really use this -- it was found to be more maintainable to keep this metainformation in the 'comps' file, external to the packages themselves. And, although this isn't intrinsic to the rpm-group vs. comps-group switch, the rpm-groups tend to be organized so that you look at the group and pick which members you want (chosing, for example, GNOME from "User Interface/Desktops") while the comps-groups are the other way around: pick "GNOME Desktop", and it installs all the GNOME bits you might want. This is generally better and more useful. The canonical list of valid RPM groups is /usr/share/doc/rpm-*/GROUPS. Theoretically, all packages should have a group listed here. But often, there's not a very good fit -- does all science and math go under "Applications/Engineering"? And even Fedora itself doesn't hold to this: there's a bunch of random "Applications/CPAN", "Networking/Other", "Desktop/Accessibility", and probably more. Now, one approach would be to reevaluate the canonical list -- reorganize it a bit, make some broader groups, and so on, and then make sure all packages properly fit that list. But that's not my suggestion. I think Group has become too ugly to be properly saved. Applications like synaptic should instead use the comps file groups for organizational purposes. In fact, there's already a lua script for at-get to make it do exactly that. (I dunno what up2date does -- I haven't used it.) Meanwhile, the Group tag itself should be reduced in function. I suggest very very vastly reduced: it should simply be "Core" for Fedora Core, "Extras" for Fedora Extras, "Legacy" for Fedora Legacy, and "Alternatives" for Fedora Alternatives. Or, if that's too much like the big disttags argument, it should simply be "Fedora", and then phased out completely. (Packages with no group would default to "Fedora", and then it could eventually stop being listed in the spec file completely.) -- Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/>
