Chapter 3. Building Custom Packages
3.1. Building packages for Red Hat Network
3.1.1. RPM Benefits
- Easy Upgrades
- Using RPM, you 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 in order to upgrade. RPM allows intelligent, fully-automated, in-place upgrades of your system. Configuration files in packages are preserved across upgrades so users do not lose 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.
- Package Querying
- RPM provides querying options that allows you to search through your entire RPM database for all packages or just for certain files. You can also easily find out what package a file belongs to and from where the package came. The files contained in the package are in a compressed archive, with a custom binary header containing useful information about the package and its contents. RPM queries the headers quickly and easily.
- System Verification
- Another feature is the ability to verify packages. If you are worried a file related to a package was deleted, you can verify the package to check the status of the files it provides. The verification notifies you of any anomalies. If errors do exist, you can reinstall the files easily. Modified configuration files are preserved during reinstallation.
- Pristine Sources
- A crucial design goal of RPM is 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, you do not necessarily have to start from scratch to make it compile. You can look at the patch to see what you 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.
3.1.2. RHN RPM Guidelines
- 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, start with 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 install without using the
--nodepsoptions. If you cannot install an RPM cleanly on your build system, Red Hat Network cannot install it automatically on a 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 highly 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.
- If a 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 package may rely upon interactive pre-install, post-install, pre-uninstall, or post-uninstall scripts. If the package requires direct user intervention during installation, it cannot 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/nullif they are not necessary. Otherwise, write them to a file.
- When creating the spec file, use the group definitions from
/usr/share/doc/rpm-<version>/GROUPS. If there is not an exact match, select the next best match.
- Use the RPM dependency feature to make sure the program runs after it is installed.
%postthat you do not clean up in a