RPMs - The HOWTO Short Story


If you like the latest and greatest version of everything and you use an RPM based system you probably want to learn how to create RPMs. You don't have to, you can just download the latest source and compile and install it in /usr/local. This of course leaves your system in a state where your RPM database does not accurately reflect what is installed on your system. Again, this will work, but building RPMs isn't (usually at least) that difficult.

First create some directories in your home directory:

  $ mkdir ~/rpm
  $ mkdir -p ~/rpm/SOURCES
  $ mkdir -p ~/rpm/SPECS
  $ mkdir -p ~/rpm/BUILD
  $ mkdir -p ~/rpm/SRPMS
  $ mkdir -p ~/rpm/RPMS

Next create an RPM macros file in your home directory:

  $ echo "%_topdir   $HOME/rpm" > $HOME/.rpmmacros

Now, get the source RPM for the program you want to upgrade. This is often the step that seems like a roadblock because if you can find the source RPM for your distro then you can usually get the compiled RPM and so there'd be no need to build it. So really this step is: create the source RPM for the program. The easy way to do this is to get the source RPM for the version that you have installed and modify it:

  • Download the source RPM for the version you have installed or the latest version that you can find for your distro. Let's say you have version 2.3.4-55 of abc on your system, so find and download abc-2.3.4-55.src.rpm.
  • Download the source code for the new version of the program. So goto abc.org and download abc-2.4.1.tar.gz and save it to ~/rpm/SOURCES.
  • Install the source RPM (as a regular user):
      $ rpm -i abc-2.3.4-55.src.rpm
    This should create a file ~/rpm/SPECS/abc.spec
  • Edit the spec file and change the old version information to the new version. There may be a few places that need changing, so take a second to examine the file and find all the places that you need to change. You may want to change the "Release" value to something "special," say 2001, so that you'll recognize it as one of yours in the future. You may also want to put a comment in the changelog section of the spec file.
  • Build the RPM:
      $ cd ~/rpm/SPECS
      $ rpmbuild -ba abc.spec
    If you have all the required tools and dependencies installed, and if luck is with you this will create RPM files in ~/RPMS/i586 or ~/RPMS/x86_64 (or something appropriate for you architecture).
  • Install the newly created RPM:
      $ sudo rpm -U ~/RPMS/i586/abc-2.4.1-2001.i586.rpm

One of the things that may give you problems are patch files. RPMs can automatically apply patches during the build process, often when upgrading to a new version some of the patches are already included in the new source distribution and so the build tries to install them again. To fix this, edit the spec file and remove the application of the patch.

If you're trying to install a program that isn't included in your distro (or the version you're currently running) you can try using a spec file from another distro or a spec file from a newer version of your distro, but this often doesn't work without a lot of spec file modification. Distros have different builtin RPM macros and assume different locations for certain things and so the spec files often need tweaking. This can even be true between different versions of the same distro, things can get rearranged and break compatibility.

With this in hand you can keep your system and your RPM database in sync, and if you can't well at least you're still running Linux.


Mitch Frazier is an Associate Editor for Linux Journal.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Building Packages in Fedora

ignacio's picture
White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState