How to use and edit comps.xml for package groups

Installation
comps is used by the installer during package selection. At the Default Packages dialog, the user can choose to Customize Now, displaying the Category Selection dialog.

In the category selection dialog, categories (as defined by the  keyword in comps.xml ) are listed down the left-hand side. If a category is selected, any groups in that category with  set are displayed in the right-hand pane. Groups have an icon associated with them. These icons come from the  package; icons are read from. If an icon does not exist for a group id, the one for the category that the group is in is used.

Once a group is selected, clicking the Optional Packages button shows Package Selection dialog.

In any group, there are four levels of packages: optional, default, mandatory, and conditional:


 * are not automatic but can be checked
 * are, but can be unchecked in a gui tool
 * are always brought in (if group is selected), and not visible in the Package Selection dialog.
 * are brought in if their  package is installed

Usually optional is the way, however if you feel that your package deserves a default or required level bring it up for discussion on the development lists. Remember that this has effect on whether or not your package winds up on distribution media such as Live images and spins.

Running System


In yum, groups are used by  and   commands, and can be queried with   command.

In PackageKit (Add / Remove Software) the upper left quadrant shows Package collections. When this is clicked, the grouping information is loaded from the configured software repositories, and the complete list of groups, stripped from their categories, are shown in the right hand pane. Selecting a group for installation causes only the default packages within the group to be installed.

Tree, Release, and Image Composition
The kickstart files in spin-kickstarts use the group definitions from comps to compose images and release trees.

When to Edit comps

 * If your app will show up in the application menu of the desktop, it should be included
 * Libraries should not be included - they will be pulled in via dependencies
 * Most text-mode utilities don't really fit in unless they have a pretty large established user-base.

If you have questions as to whether it makes sense or not, feel free to post to the development list.

Some guidelines on specific groups in comps follows.

New groups
Please consult devel@lists.fedoraproject.org before adding new groups.

New group names and descriptions are translatable strings. Do not add new groups, or change their descriptions, during a string freeze. Please check the release schedule for these dates.

Core
Core is not visible, so adding 'default' or 'optional' packages to it isn't needed. Boot loaders are listed as 'default' in the group so that they're pulled in by compose tools.

Core is installed on every installation, so adding packages to it is discouraged.

GNOME Desktop
The gnome-desktop group is maintained by the Desktop SIG. Please run changes through desktop@lists.fedorarproject.org.

KDE Desktop
The kde-desktop group is maintained by the KDE SIG. Please run changes by them.

Fonts
The following is part of the Fonts SIG   packaging rules.

Language support groups
Language support groups are selected automatically if you are installing in the specified language, and manually otherwise. Language support groups require the  key, which should be set to ISO 639-1 two-letter language code for that language, or the ISO 639-2 bibliography code, if that does not exist. These codes can be looked up in the  package.

Each language support group should have the following conditional packages, if the packages exist:


 * hunspell dictionary for the language (requires hunspell)
 * aspell dictionary for the language (requires aspell)
 * openoffice.org langpack (requires openoffice.org-core)
 * KDE 4 translations (kde-l10n-XXX,requires kdelibs)
 * KDE 3 translations (kde-i18n-XXX,requires kdelibs3)
 * KOffice langpack (requires koffice)
 * Eclipse NLS support (requires eclipse-platform)
 * man page translation (requires man-pages)
 * gcompris sounds for the language (requires gcompris)
 * moodle translations (requires moodle)

There may be other language specific subpackages necessary; this is not a fully inclusive list.

Each language support group should have mandatory packages for:


 * fonts required for that locale (consult the Fonts SIG)
 * input methods, and data, required for that locale (consult the I18N SIG)

Each language support group can have optional packages for:


 * additional fonts that support that locale (consult the Fonts SIG)

New language support groups need added to the  category in the comps file.

All other groups
When making changes to the default or mandatory packages, strive for consensus, and consult the development lists as necessary. If you're unsure, you can also file a bug against the comps component in bugzilla.

How to edit comps
Clone the comps GIT module in Fedora Hosted:

Find a reasonable group in the comps-fnxml.in file (where n represents the release number) for your package. If your package is not listed there, please add it using the following as a template if your package were named "foo":

foo


 * Make sure to preserve the alphabetical order in each group.
 * Make sure to run xmllint on the result to check you didn't make a mistake in the XML syntax.

You can use the provided xslt filter to sort, indent and check the syntax of your comps file in one run:

$ xsltproc --novalid -o sorted-file comps-cleanup.xsl original-file

The filter will warn you if it removes redundant information or if something needs to be checked by a human.

Commit your changes. You can then push your changes to the repository with.

Please make sure to run  right before   to avoid overwriting other people's changes as much as possible.

Current status
You can check our current comps status file here.