Building a custom CentOS 5 kickstart disc, part 2

Note: this series of articles applies to CentOS 5; for CentOS 6, see this series.

Once you’ve decided which packages you’re going to include in your kickstart disc, it’s time to pull them all together.

Which RPMs do you need? Assuming that you are including at least the @core and @base package groups (and you should), you’ll need the RPMs for all the packages in those groups.

One way to obtain the list of RPMs you need is to look in the file comps.xml for the core and base groups. You will see XML like this:

At a bare minimum, you will want all the required packages from within the base and core groups. Look for <packagereq type=”mandatory”> and <packagereq type=”default”> entries within the <group> tags. This tells you which packages to get. These package names correspond to the names of the RPM files.

To make this easier, I have built a script to parse the comps.xml file and gather all the non-optional packages for the base and core package groups. Download parse_comps.pl and save it in your ~/kickstart_build directory.

Run it this way:

Add your own RPMs

If you want to add any RPMs not included in the base and core groups (for example, httpd, php, or mysql), copy those into the ~/kickstart_build/isolinux/CentOS directory at this time.

Gather dependencies

Now we have all the base and core RPMs in our ~/kickstart_build/isolinux/CentOS directory, along with any other RPMs you’ve added, but many are missing their dependencies. So the next step is to track down all the dependencies of these packages and throw those into the directory, too. You can use another script, follow_deps.pl, to perform this step.

Testing dependencies

Once you’ve got a set of RPMs ready, you’ll need to test the dependencies of the RPMs. Each RPM may require that other RPMs be installed in order for it to be installed. If each RPM’s dependencies are included in the set of RPMs, then all the dependencies are resolved. The objective is to have a set of RPMs that have no unresolved dependencies.

To test the dependencies in your set of RPMs, run these commands:

If you find you have unresolved dependencies (and you will almost certainly have some), you can do one of two things:

• remove the RPM with the unresolved dependencies (a good idea if the RPM is going to set off a chain of dependencies that you don’t want, for example X Windows on a server class installation)
• track down the RPMs to fulfill the dependency

Here, again, you need a little bit of savvy to determine which packages should be removed. In general, if the package is one that you explicitly added to the base and core groups, then you’ll probably want to find the dependencies and include them. If it’s an RPM that you don’t really want (one that got matched by the wildcard, for example), you might decide to eliminate that RPM.

Resolving dependencies

The follow_deps.pl script should get all your dependencies automatically. But if it doesn’t (and it might not, especially if you’ve added some additional RPMs to the mix), you’ll have to track down the dependencies manually.

Finding the RPMs to satisfy dependencies can be easier said than done. Sometimes the capability dependencies listed don’t match the name of the RPM. For example, you might get something like:

It turns out that /usr/bin/strip is provided by binutils.

If you’re not sure what RPM provides one of these dependencies, you can use RPM itself to query for the right package (assuming the right package is installed on the queried system — this is where it is very helpful to have a machine that has all the RPMs installed).

This is an iterative process. Be prepared to spend a while chasing down these dependencies to build a fine-tuned collection of RPMs with no unresolved dependencies.

The next step is to build your disk image. I will cover that in the next installment.

part 1 · part 3 · part 4