RPM Packaging for Sysadmins

On Sunday afternoon, David Nalley presented a training session entitled "RPM Packaging for Sysadmins". Although it's technically a new course for LISA '11, it's actually a retooling of a more general packaging class that was offered several years ago. The old course covered Debian and Solaris packaging, but the attendee feedback indicated that the vast majority were only interested in learning RPM.

The course starts with explaining why bother packaging. The traditional autoconf command chain of

./configure; make; make install

is fine for temporary systems, but David argues that such things don't exist. As a result, software package installation needs to be automated for repeatability and consistency. Additionally, RPM package provide additional source of documentation for how a particular package is installed. David also argues that having compilers on hosts is an unnecessary security risk, so confining compilers to package build systems makes sense in that context.

Newer distributions contain extra tools to make package creation easier. The rpmdev-setuptree automatically creates the necessary directories for building RPMs. rpmlint provides feedback on the correctness of the RPM spec file, including spell checking. Installation of RPMs can be tested with mock, a chroot-like environment that performs testing against a pristine system.

As in writing code, RPM spec files are best when nothing is hard-coded. RPM installations provide plenty of pre-defined macros that aid in building for multiple architectures and distributions. Additional macros can be defined for ease of use and reusability.

The meat of building RPMs is the spec file, which defines the build steps and package metadata. The first section is the headers, which contains statements including the package name, version, release (build number of a particular source version), requirements for build time and runtime, license, packager, etc. The next section contains script definitions, which control the preparation of the source tree, the configuration, and compiling. Additional scripts can be defined to perform pre- or post-steps for package installation and removal. The final section is a changelog, which should contain not only changes to source but also changes to the spec file.

The last third of the class was devoted to a set of hands-on exercises. This gave attendees a chance to practice what they learned. There's a great deal more that can be learned about RPM packaging, but this is a great introduction to building packages.