The comps file defines how the packages are bundled during the installation. In the Red Hat distribution, this is done according to the functionality they provide, for example:
Printer Support
X Window System
GNOME
KDE
Mail/WWW/News Tools
...
Kernel Development
Extra Documentation
Sometime during the installation process, the user is presented with a dialog called "Components to install". Some of the components have been preselected, and others not. The last item on the components list is called "Everything". On the dialog box, there is also an option that enables the user to customize exactly what packages will be installed. Customizing the installation by hand, or selecting "Everything" in the components list is the only way to have your own packages installed unless you modify the RedHat/base/comps file.
The comps file currently starts with a header describing the version of the comps format, followed by an empty line.
0.1
<empty line>
|
After this, the components are listed, separated by empty lines:
<component 1>
<empty line>
<component 2>
<empty line>
....
<component n>
<empty line>
EOF
|
Each component has the following definition:
(0|1) (--hide)? <name>
<RPM 1>
<RPM 2>
...
<RPM n>
end
|
Before the name of each component, 0 or 1 is given. A value of 1 here means that the component is chosen by default, and 0 means it's not. The option --hide means that you will not see the entry, unless you choose "expert" installation. The first component is called "Base", and that is special, in the sense that it must be present and it does not show up in the dialog (you can't deselect the base installation, which makes sense...). Next follows a list of rpm packages belonging to that component. Note that this is the package name stored in the rpm file, and not any part of the file name of the package (although it should be the same by convention).
By adding your packages to the comps file, you can customize your own distribution, and make sure that your packages will be installed by default. One thing to be careful about is interdependence among your packages, but here, you are on your own :-) A word of warning: be careful not to add or remove extra whitespace in the file. Examine the existing comps file (make a copy of the original) to see how it's done (or check i386/misc/src/install/pkgs.c if you want to see how the file is parsed).
With RedHat version 6.1, the format of the comps file has changed. The decoding takes place in ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. I didn't analyze yet this python script and the following rules were obtained only by reading the file and testing some configurations for it.
In release 6.1, the definition of component is extended to include some more optional elements beside the <RPM> ones. These elements are:
<arch-dependent-RPM 1>
...
<arch-dependent-RPM n>
<required-component 1>
...
<required-component n>
<component-dependent-RPM 1>
...
<component-dependent-RPM n>
|
An <arch-dependent-RPM> defines a dependency between a package and specific architecture and has the following definition:
(!)?arch: <RPM>
|
So it can, for example, present itself, in the real world, as:
!alpha: kernelcfg
|
Or as:
i386: mkbootdisk
|
A <required-component1> enforces the dependency from another component and is defined as:
@ <component>
|
So, for example, if inside a component definition you find the following line:
@ Networked Workstation
|
A <component-dependent-RPM> is used to select the installation of some additional packages for a component, given the presence of another component. Its definition is as follows:
? <component> {
<RPM 1>
...
<RPM n>
}
|
So if, for example, in a component definition, you happen to read the following lines:
? KDE {
kpppload
}
|
With RedHat version 6.2, the format of the comps file has, apparently, changed just slightly. The decoding takes place in ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py even in this case. Once again, I didn't analyze yet this python script and the following rules were obtained only by reading the file and testing some configurations for it.
In release 6.2, the definition of component is extended to include two more optional elements which are:
<lang-dependent-RPM 1>
...
<lang-dependent-RPM n>
<arch-dependent-component 1>
...
<arch-dependent-component n>
|
A <lang-dependent-RPM> is needed to specify the installation of a package in case a specific language was selected. It's defined as:
(lang <language>): <RPM>
|
For example, the following line:
(lang ja_JP)): locale-ja
|
An <arch-dependent-component> extends the concept of <arch-dependent-RPM> introduced in release 6.1 to an entire component, as you can understand reading the definition:
(!)?arch: <component>
|
With RedHat version 7.3, the format of the comps file has gained some more syntactical power. The decoding takes place (again) in the comps.py script, which you can now find in the /usr/lib/anaconda/ directory if you have installed the anaconda package. The dependencies on a language or an architecture by a component or a package can now be joined with the and operator. For example:
(arch !s390 and arch !s390x and arch !ia64): readline2.2.1
|
which means if architecture is not any of s390, s390x, ia64 then install the package readline2.2.1. This can be done with components instead of packages and languages instead of architectures. All this, is definitely more than enough for the simple examples of customization of the default installation which will be presented in the next section.
The example we will go through in this section implies modifications to the comps file to change the default values for packages installation. I usually prefer, in fact, particularly in certain situations a default installation including only the base packages, with some slight alterations to some of them. In the first of the presented examples, we will build a default installation which has the libsafe added to the "Base" component and most of the packages which are usually installed by default are deselected, so to build a minimal installation. In the second of the examples, we will modify some of the components to build another minimal installation which fits (this time, almost perfectly) our needs (they are, actually, my needs, your mileage may definitely vary). If you want to include a modified comps file in your CDs, you should copy it into the main tree just before starting the operations described in Rebuilding the 7.3/8.0 installer.
To customize your installation this way, you have to edit the comps file with your favourite text editor (pay attention not to leave harmful spaces or tabs in the file) and move it to the Redhat/base directory overwriting the original one.
In the first comps file included, the libsafe package was added to the "Base system" component and almost every component was deselected so to have a default installation comprising only two hundred packages (I know they can still be too many...).
In the second comps file included, we build on the previous setup and strip down the default installation a bit more (this time there will be only 154 packages in the default installation). Some of the groups have been splitted to give the installation some more granularity. All the modifications you do should take into account the interdependencies among packages and the applications used during the installation phases (you cannot remove kudzu, for example, from the Base component, even if you can do it after installation). It must be said that similar results can be obtained using kickstart. For more informations about it, you can read The RedHat Linux Customization Guide.
With RedHat version 8.0 and 9, the format of the comps file has changed completely and now an XML file, whose name is comps.xml, is used. Details on the file syntax can be found in the anaconda comps section of the RedHat website.
We will now reproduce the examples presented for release 7.3 taking into account the modifications the various groups were submitted to. The most important group (the "Base" group) is splitted here in two groups which are named "Base" and "Core". The "Base" group should represent the minimal possible installation.
This time, to customize your installation you have to edit the comps-milan.xml.in file with your favourite text editor. This file can be found in the comps-8.0.tar.gz archive found on the Redhat website. To add the packages information to the file you create, you need to have the comps-extras rpm package installed. The commands to be issued to complete the operation are listed in Updating comps.xml and in the documentation. After you create the file, you have to copy it to the Redhat/base directory overwriting the original one. If you are using the updateBuild.sh script, you should only copy the comps-milan.xml, (after having modified the comps-milan.xml.in found in the comps-8.0.tar.gz tar/gzip package and issued the make command), to the destination you should have already configured in the COMPSFILE variable (rhcd.conf).
In the first comps file included the libsafe package was added to the "Base" group (component) and almost every group (component) was deselected, apart from "Base" and "Core", so to have a default installation comprising only ~220 packages (probably too many, again...).
In the second comps file included, we build on the previous setup and strip down the default installation a bit more (this time, there will be only 158 packages in the default installation). Once again, similar results can be obtained using kickstart, for more informations about it you can read The RedHat Linux Customization Guide. In the example, I didn't unselect completely the installation of the "Base" group, because there are too many packages I usually need, so I just unselected the default installation for these packages making them optional. As you can see, even the redhat-logos package in the "Core" group was made optional. Considering that all of the packages in this group, together, should represent the smallest possible installation, you probably don't want to do this (by the way my CDs work even with this, there should be some failure I cannot see, yet). The tripwire package was also added to the "Base" group. The last noticeable modification was made to the "dialup" group, which will be installed even if unselected because the "Base" group depends on it (as declared in the group definition itself). I have selected only some packages I usually need from this group for installation and left the rest of them unselected.
We will reproduce (again) the examples presented for release 7.3/8 taking into account the modifications the various groups were submitted to.
As in the case of 8.0, to customize your installation you have to edit the comps-milan.xml.in file with your favourite text editor. This file can be found in the comps-9.tar.gz file among the script (as I said it is not the same you can find on the Redhat website). To add the packages information to the file you create, you need to have the comps-extras rpm package installed. The commands to be issued to complete the operation are listed in Updating comps.xml and in the documentation. After you create the file, you have to copy it to the Redhat/base directory overwriting the original one. If you are using the updateBuild.sh script, you should only copy the comps-milan.xml, (after having modified the comps-milan.xml.in found in the comps-9.tar.gz tar/gzip package and issued the make command), to the destination you should have already configured in the COMPSFILE variable (rhcd.conf).
In the first comps file included the libsafe package was added to the "Base" group (component) and almost every group (component) was deselected, apart from "Base" and "Core", so to have a default installation comprising only ~240 packages (mmmhhh complexity is raising high...).
In the second comps file included, we build on the previous setup and strip down the default installation a bit more (this time, there will be only ~175 packages in the default installation). This is really similar to the example presented for Redhat 8.0, so I will avoid boring you with the same explanations. Once again, similar results can be obtained using kickstart, for more informations about it you can read The RedHat Linux Customization Guide.