There are many things that might go wrong when building packages. This is especially true when these packages must be delivered and installed through Red Hat Network. This chapter describes how to build packages of the highest quality that may be successfully delivered via Red Hat Network.
Red Hat Network uses the RPM Package Manager (RPM) technology to determine what software additions and updates are applicable to each client system. Thus, all packages retrieved from Red Hat Network must be in RPM format. (Entire ISO images, however, are also available through the Software tab of the RHN Web interface.)
RPM is an extremely powerful tool that provides users with a simple method for installing, uninstalling, upgrading, and verifying software packages. It also allows software developers to package the source code and compiled versions of a program for end users.
RPM provides the following advantages:
Using RPM, you can upgrade individual components of a system without completely reinstalling. When Red Hat releases a new version of Red Hat Enterprise Linux, users do not have to reinstall (as they do with operating systems based on other packaging systems). RPM allows intelligent, fully-automated, in-place upgrades of your system. Configuration files in packages are preserved across upgrades so users do not lose their customizations. There are no special upgrade files needed to update a package because the same RPM file is used to install and upgrade the package.
RPM is designed to provide powerful querying options. Users can search through their entire RPM database for all packages or just for certain files. Users can also easily find out what package a file belongs to and from where the package came. The files an RPM package contains are in a compressed archive, with a custom binary header containing useful information about the package and its contents, allowing you to query individual packages quickly and easily.
Another powerful feature is the ability to verify packages. If users are worried they deleted an important file from a package, they can simply verify the package. They will be notified of any anomalies. If errors do exist, they can reinstall the questionable package easily. Modified configuration files are preserved during reinstallation.
A crucial design goal was to allow the use of pristine software sources, as distributed by the original authors of the software. With RPM, the pristine sources can be packaged, along with any patches that were used, plus complete build instructions. This is an important advantage for several reasons. For instance, if a new version of a program is released, users do not necessarily have to start from scratch to make it compile. Users can look at the patch to see what they might need to do. All the compiled-in defaults and changes made to get the software to build properly are easily visible using this technique.
Keeping sources pristine may seem important only to developers, but it results in higher quality software for end users, as well.
The strength of RPM lies in its ability to define dependencies and identify conflicts accurately. Red Hat Network relies heavily on this aspect of RPM. Red Hat Network offers an automated environment, which means that no manual intervention can take place during the installation of a package. Therefore, when building RPMs for distribution through Red Hat Network, it is imperative to follow these rules:
Learn RPM. It is crucial to have a fundamental understanding of the important features of RPM to build packages properly. For more information about RPM, consult the following resources:
When building an RPM for a child channel, build the package on a fresh install of Red Hat Enterprise Linux of the same version as the child's base channel. Be sure to apply all updates from Red Hat Network first.
The RPM package must be able to be installed without using the --force or --nodeps options. If you cannot install an RPM cleanly on your build system, Red Hat Network will not be able to install it automatically on a user's system.
The RPM package filename must be in the NVR (name, version, release) format and must contain the architecture for the package. The proper format is name-version-release.arch.rpm. For example, a valid RPM package filename is pkgname-0.84-1.i386.rpm, where name is pkgname, version is 0.84, release is 1, and arch is i386.
The RPM package should be signed by the maintainer of the package. Unsigned packages may be distributed through Red Hat Network, but the Red Hat Update Agent (up2date) must be forced to accept them. Signing packages is recommended and is covered in Section 3.2 Digital Signatures for RHN Packages.
If the package is changed in any way, including changing the signature or recompiling, the version or release must be increased incrementally. In other words, the NVRA (including architecture) for each RPM distributed through RHN must correspond to a unique build to avoid ambiguities.
No RPM package may obsolete itself. This may seem obvious, but it bears mentioning.
If an RPM package is split into separate packages, be extremely careful with the dependencies. Do not split an existing package unless there is a compelling reason to do so.
No RPM package may rely upon interactive pre-install, post-install, pre-uninstall or post-uninstall scripts. If the RPM requires direct user intervention during installation, it will not work with Red Hat Network.
Any pre-install, post-install, pre-uninstall, and post-uninstall scripts should never write anything to stderr or stdout. Redirect the messages to /dev/null if they are not necessary or write them to a file.
When creating the spec file, use the group definitions from /usr/share/doc/rpm-*/GROUPS. If there is not an exact match, select the next best match.
Use the RPM dependency feature to make sure the program will run after it is installed.
It may be tempting to create an RPM by archiving files and then unarchiving them in the post-install script, but do not do it. This defeats the purpose of RPM. If the files in the archive are not included in the file list, they cannot be verified or examined for conflicts. In the vast majority of cases, RPM itself can pack and unpack archives most effectively anyway. For instance, don't create files in a %post that you don't clean up in a %postun section.