> Only if the group field is useful...which it isnt, if yer suppose to > stick with the canonical groupnames as mentioned in the parent post. > Some yum mirrors understand yum's group commands that work of of > comps.xml file definitions. Hell even if you are using a Fedora Core > mirror with yum that doesnt support yum's group features you can steal > the comps.xml file and stick it in yer yum cache and get the group > functionality back. Hell...you can even imagine having people create > personalized comps.xml files for use with yum that regroup the same > repository to better suit their needs. There is no reason that each > repo can not define their own comps.xml groupings to be useful both as > a way to group categories in a way that makes intuitive sense for that > repository and to use as a metapackage installation method. Usage of > comps.xml files at all repositories makes sense, if there is any > desire to make it possible for people to use 3rd party media sets at > install time (at some point in the future) or when > system-config-packages gets rebaked to include support for repos. To that point. http://linux.duke.edu/projects/yum/download/misc/yumgengroups.py That script lets you relatively easily generate your own yumgroups.xml file. yum will merge groups files b/t repositories - but packages from any repository can be listed in any yumgroups.xml file. -sv
