Building RPMs Yourself

If you are familiar with the make-based way to build and install software packages in Unix systems, this page should enable you to step to a higher level, using RedHat's Package Manager (RPM).

Contents

1. About RPM
2. RPM Setup
3. RPM Usage Examples
4. Recommendations

About RPM

RPM is a fundamental part of RedHat Linux as well as of SuSE Linux and some other Linux distributions. RPM is not the only available package manager, but if you have an RPM-based Linux distribution, you should learn to use it, particularly if you would otherwise build and install software directly with make. Using a package manager facilitates proper uninstalling and upgrading of packages, and a package manager has additional useful features, namely the capabilities to identify the package of any installed file, and to detect changes to the installed packages.

I won't give an extensive RPM tutorial here; if you have RPM, you also have some introductory documentation, e.g. the RPM-HOWTO and the manpage rpm(1). You can also look at Ed Bailey's book Maximum RPM, available from RedHat.

Some explanatory words may be appropriate though. Typically, you build and test a software package as described in the package's installation instructions, possibly find some bugs and apply some patches. Then you fake an install, usually by overriding variables such as prefix or DESTDIR in the make install command so that e.g. files for the /usr tree get into /var/tmp/foo-root/usr (say). In this example, /var/tmp/foo-root is what RPM calls the buildroot for package foo. Then you inspect the buildroot-ed tree to find out what files get installed. Finally, you record all this information, including detailed patch, build, and install commands, and the file list, together with some overall information about the package in a so-called specfile.

Given that specfile, RPM can redo the complete sequence from unpacking and patching the sources, through building to (faked) installing. RPM collects the to-be-installed files into one or more binary packages. This does not require root privileges because you don't really write into restricted areas of your system. You can actually install binary RPM packages with a separate RPM command which requires root permissions. RPM records data about all installed packages and their files in a database and uses that information for other administrative tasks such as testing for changes, upgrading, or uninstalling.

RPM can also make a so-called source RPM package which contains all the stuff needed to build the binary RPM package, that is, source tarballs, patch files, and the specfile. Thus, everything you need to rebuild the package is bundled together conveniently.

From what has been said, it should be clear that all you need to get some foo.tar.gz built automatically by RPM is a specfile and, occasionally, patch files. Some nice developers include specfiles in the tarballs they release, and RPM can build such tarballs directly.

RPM Setup

The following hints assume that you have a system with installed RPM, which is true for RPM-based Linux distributions of course.

• If you are new to RPM, make sure that you have a suitable optflags setting in your /etc/rpmrc or elsewhere. You can check the result with the command

  rpm --eval '%{optflags}'
  

  Some people like highest optimization levels, but I think that GCC's -O2 is enough and can protect you from quite a few optimizer bugs. For a Pentium-II, I typically use the flags -mcpu=i686 -O2 -fstrict-aliasing -Wall -Wno-unused.

• As a supplement, you may want to prepare a /usr/share/config.site file that contains your default settings for GNU configure. This is useful even without RPM. Check the autoconf documentation for details.

• Find out where RPM expects to find source tarballs and specs, where RPM would do its building, where it would place resulting packages etc. Typically, this is done in subdirectories of %{_topdir}, so you can get an answer by issuing the command

  rpm --eval '%{_topdir}'
  

  Normally, the subdirectories of %{_topdir} are world-writable, so that regular users can build packages. If you prefer to work in your own home directory, prepare a ~/.rpmmacros file with contents like

  # Use the home directory for building.
  # Needed dirs (or symlinks): BUILD RPMS/i386 SOURCES SPECS SRPMS
  %home           /home/chris
  %_topdir        %{home}
  %_tmppath       %{_builddir}
  %buildroot      %{_tmppath}/%{name}-root
  

RPM Usage Examples

Assume that you want to build the package foo from sources in foo-1.0.tar.gz using RPM. Assume further that you have (prepared or got) a specfile and perhaps some patches for foo-1.0.

1. Move the source tarball and the patch files into the directory where RPM expects to find sources, e.g. /usr/src/packages/SOURCES/. You may also want to place the specfile to the corresponding SPECS directory.

2. Issue the command rpm -ba foo.spec, where foo.spec is the pathname of the specfile. (Include directory components if necessary.) If everything goes well, this builds (-b) both source and binary RPM packages (-a) and stores these in e.g. /usr/src/packages/SRPMS/ and /usr/src/packages/RPMS/i386/, respectively. The actual building happens in a subdirectory of /usr/src/packages/BUILD/, and the buildroot for the installation may be a subdirectory of /var/tmp/.

   I recommend that you capture the screen output into a logfile by refining the above command to

   rpm -ba foo.spec 2>&1 | tee foo-1.0.log
   

   The logfile can help you in case of errors, and of course it should always be scanned for warnings and other strange things.

3. Get root permissions and (really) install the package with

   rpm -Uvh /usr/src/packages/RPMS/i386/foo-1.0-1.i386.rpm   # or whatever
   

   Now the package is properly integrated in your system. (Note: -U means upgrade package, the -vh just prints a progress bar.)

4. Once you are satisfied with the package, you may remove the build tree in /usr/src/packages/BUILD/. This can either be done directly or via the command

   rpm --clean foo.spec
   

   (Note that this --clean option is not related to the specfile's %clean section which undoes the pseudo-installation. When building binary RPMs, the %clean commands are executed automatically in case of success, but the build tree remains unless the --clean option is given.)

5. Similarly, you can remove the source tarball and the patch files from /usr/src/packages/SOURCES/ because you have a source RPM now. (Have you?) RPM can do this for you if you give the command

   rpm --rmsource foo.spec
   

   Note that this still leaves the specfile, though it is also contained in the source RPM. You can remove the specfile manually or with the option --rmspec.

6. Note also that the options --clean and --rmsource can as well be given in the rpm -b command. That is, you can build the RPM packages with subsequent proper cleanup by giving the single command

   rpm -ba --clean --rmsource foo.spec 2>&1 | tee foo-1.0.log
   

7. Should you ever need the sources and the specfile again, you can unpack the source RPM package by telling RPM to install it:

   rpm -i /usr/src/packages/SRPMS/foo-1.0-1.src.rpm
   

   In contrast to the installation of a binary RPM, the installation of a source RPM does not require extra privileges as long as the SOURCES and SPECS directories are writable.

8. In the special case where you just want to unpack the source RPM, build the binary RPM from its contents, and clean up, a single command suffices:

   rpm --rebuild /usr/src/packages/SRPMS/foo-1.0-1.src.rpm 2>&1 | tee foo-1.0.log
   

Recommendations

• Before you use the specfile, glance through it. I sometimes comment out some applicable parts, e.g. patches for experimental features, or time-consuming make check commands, which you may want to try. Or you may want to comment out certain Require directives that demand packages you have actually installed, but with a different name. And of course, the specfile comments may contain helpful usage information.

• Note that most patches are specific to a particular package version. Later versions may be fixed already, in the same or another way than the one suggested by the patches, or may not be fixed, but the patches could then be incomplete or inappropriate or could fail to apply for some reasons.

  If you update a specfile for a newer version, you should disable all previous patches. You could try to find out whether the old patches would still apply and, by careful inspection of the source code, whether they should be applied and what further adaptation could be necessary. The best result would be an updated patch file that fits properly to the new version.

• RPM appends a release number to every version number. Let the version number mirror the official version of the package you downloaded, and count your own modifications of that package with the release number. If you modify the package without upgrading to a new official tarball, simply increment the release number in the specfile. If you build a new official version, update the version number in the specfile. Then you can reset the release number to 0 or 1.

• Once you have built some RPMs, you may want to share them with the community. Binary RPMs are ready for installation and thus can be very convenient, but they carry a lot of dependencies specific to the build system. There is the machine type, of course, plus specific dynamic library versions required for the executables, and some other things which make binary RPMs less portable. RPM detects most of these cases and (by default) refuses to install RPMs with unsatisfied dependencies. Such a binary RPM package is rather useless. It won't even help a user if he decides to build the package himself, because the specfile is elsewhere, in the source RPM. These restrictions are encountered again when it comes to upgrades.

  The specfile can often be used with very few modifications to build later versions of the package. That's why I post specfiles and patches only. The other sources can be downloaded from the offical sites, and when you are there, you can check for the newest versions as well.

• Report your patches to the package authors so that you don't have to do the patching again when upgrading next time.

• If you found the specfile at my website, report specfile changes to me, if you like.