RPM .spec Files

Paul Heinlein
First published on April 5, 2004
Last updated on August 12, 2005

One of my duties at work is building and maintaining software for systems running the Red Hat and Fedora Core Linux distributions. The Red Hat Packaging Manager (rpm) system is far from perfect, but it’s still very useful.

Red Hat and Fedora Core ship with an ever-increasing variety of packages, but there are still some useful ones that don’t get included—and a few that do get included but that are out of date for my purposes. So I’ve built my own packages to keep my systems a-hummin’.

The .spec file

At the heart of the rpm building process is the .spec file. It governs how a package is configured, what patches are applied, what files will be installed and where they’ll be installed, and what system-level activity needs to take place before and after a package is installed.

Below are some .spec files that I’ve devised. I should note that while the packages they produce work quite well for me, they haven’t been tested in any methodical way.

If you’re looking to build serious production-quality packages, you might be better off studying the .spec files at Fedora Extras, Fresh RPMS, DAG, or ATrpms. The packages at Fedora Extras, in particular, are subjected to a fairly rigorous QA process and are of consistently high quality.

Home-brewed .spec files

In the .spec files listed below, you’ll often see reference to a variable named redhatvers. It lets me build packages that are explicitly tied to a certain Red Hat or Fedora release. I define that variable in /etc/rpm/macros:

%redhatvers       fc2

It shouldn’t make any difference if you don’t have it defined on your system (at least, that’s the theory <grin>).

I leave to you the task of locating and retrieving the source tarballs for each of these packages, though you should find some helpful URLs in the .spec files themselves to get you pointed in the right direction. Happy building!

Building a binary package

I’ll provide the barest of outlines of the procedure you need to follow to build a binary RPM package. If you need more information than I provide, or if something goes wrong, you’ll need to research some of the resources listed in my “getting started” section, below.

Download the .spec file; it needn’t be put into any specific directory.

Download any sources and patches needed by the .spec file and install them into the RPM source directory.

On Red Hat and Fedora systems, the default path for that directory is /usr/src/redhat/SOURCES. You can verify that path by polling rpm for the value of the _sourcedir macro.

rpm --eval '%{_sourcedir}'

Build the source and binary packages.

rpmbuild -ba /path/to/foo.spec

If successful, the rpm-building process will end by telling you the locations of the newly built packages, e.g.,

Wrote: /usr/src/redhat/SRPMS/foo-1.23-1.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/foo-1.23-1.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/foo-debuginfo-1.23-1.i386.rpm

Install or update the new binary package.

rpm -Uvh /usr/src/redhat/RPMS/i386/foo-1.23-1.i386.rpm

Getting started with RPM building

Someone once asked, “How do I go about learning about all this RPM goodness?” Here’s what I did/do:

  • Read the online copy of Maximum RPM

  • Poke through the .spec files in the source packages (SRPMS) that come with your distribution. GNU Midnight Commander (mc) will do all the cpio magic behind the scenes so you can explore source packages quickly and easily. If you don’t have mc on your local system, you can unpack an SRPM manually:

    rpm2cpio foo-1.23.src.rpm | cpio -id

  • Macros are at the core of RPM packaging. There are macros for everything: directory locations, compiler optimizations, etc. On Red Hat and Fedora systems, you’ll want to look at all the macros files in the /usr/lib/rpm directory tree. You can locate them all in one fell swoop:

    find /usr/lib/rpm -name macros

  • Grok a copy of ``; you’ll learn some cool things about packaging Perl CPAN modules. (Or you can just use cpan2rpm and not worry about the details. :-)

  • If you end up doing a lot of RPM work, join the rpm-list mailing list. In particular, Jeff Johnson, the lead RPM developer at Red Hat, is very helpful—and usually very quick to answer questions.