Packages should have category information attached to them so it is possible for users to browse for packages. Currently, we have the RPM Group tag and comps.xml for this.
The RPM Group Tag is not good for this because: 1. The group tag only takes a single group. 2. There's no easy way to prevent mispellings, users creating off-the-wall new groups, etc. 3. Categorization information should live outside of the package as different people composing package groups may want to include different sets of packages into the groups.
Comps.xml was originally designed for use by anaconda. Anaconda's UI is not intended for expressing things like packages selectable from several groups, large numbers of groups, deep hierarchies of groups, or packages which only some end users may be interested in installing. Therefore, the anaconda devs want to keep the comps.xml they use small and succinct. Other UIs would benefit from having category information for all packages in the repository. One solution to this conflict is to have two comps.xml files, one which the installer uses and a separate one that has full information. Seth Vidal outlines part of how this could work here: https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00672.html
Jeremy Katz has several issues with reusing comps: 1. comps.xml wasn't designed for this and he thinks it isn't the right format to encode the information. 2. He doesn't want comps.xml which lists all the packages in the repo to interfere with the comps.xml for anaconda.
Nicolas Mailhot proposed an alternative format to comps.xml:
https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00700.html
https://www.redhat.com/archives/fedora-extras-list/2006-November/msg00702.html
https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00012.html
https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00017.html
There are two things that set his proposal apart from the current comps.xml: 1. The separation of groups and categories. There can be 1000s of categories. The packager adds any number of categories to each of their packages. Then a distro maintainer/package manager/etc can create a profile that defines groups which encompass whole categories. 2. Ability for the profile writer to use logical operators (and, not) in the groups to add categories but exclude/include specific packages.
Christien Iseli posted a list of use cases from different roles:
Things I'd like to do from a user point of view: - see what apps are available for performing some tasks, e.g. create video DVD, develop and test that new python package, ... - have an easy way to select the packages I find useful and install them Things I'd like to do from a packager point of view: - attach some grouping info to my packages, e.g., this package is a bioinformatics tool, it is meant to run in a KDE environment, ... - be able to tell e.g. fellow bioinformaticians: just do a "yum groupinstall bioinformatic-tools" and you will be good to go - not have to enter redundant info into many different files Things I suspect a release creator would like to do: - define a set of packages that should get installed when the user chooses a certain type of install, e.g.: o KDE desktop o GNOME desktop o web server o barebone minimal Things I'd like to do from a QA point of view: - make sure all packages get consciously assigned to the proper group(s) - easily verify the correctness of the comps.xml file
https://www.redhat.com/archives/fedora-extras-list/2006-December/msg00034.html