On Tue, 25 May 2004 21:20:51 -0400, Brad Smith <brads@xxxxxxxxxx> wrote: > If so, what about packages that don't appear in comps.xml? Let's face > it, a lot of people are going to install packages from the third-party > repos and it would be awkward at best to just have them all lumped into > an "Other" category. Once repos start producing their own comps.xml files, and the management tools understand you to handle repo specific comps.xml files...there is no all encompassing "Other" category. > Plus I have a personal interest in doing the opposite of what you're > suggesting. Currently the headers stored on apt and yum servers don't > include the Group field though it would be great for people to be able > to search by in Fedora Tracker. Thus I'm very pleased that the new XML > metadata format does include this information. 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. Relying on the somewhat static and inflexible Group tag that rpm knows about is revisionist history at this point. The base distro tools have moved very far away from that and rely heavily on comps information now. Instead of moving back in time, we need to move forward and make usage of the comps file MORE pervasive and build tools to help repos build and maintainer their own comps files that provide the grouping information to the distro tools that understand grouping. -jef