May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Building RPMs

News Recommended Links Cheat sheet Tutorials Reference YUM
--aid option Installation/Removal Verification Queries Examples YAST
RPM-related PERL Modules and Utilities Autoupdates Creating custom RPMs RPM-based integrity checking Humor Etc

RPM concept is somewhat similar to self-installable archive popular in DOS world and available in all major archivers, such a RAR.  It is more structured and more tunes to software installation. Every RPM package has a package label, which contains the following pieces of information:

RPM file names normally have the following format:


For example:


A package label is contained within the file and does not necessarily need to match the name of the file. Source code may also be distributed in RPM packages. Such package labels do not have an architecture part and replace it with "src", e.g.:


Additionally, libraries are distributed in two separate packages for each version. One contains the precompiled code, while the second one contains the development files such as headers, static library files, etc. for the library in question. Those packages have "-devel" appended to their name field.

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.

RPM Setup

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

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



RPM packages are created from RPM spec files using the rpmbuild tool. When building an RPM pachge you need to create the directory with the name of the package and several predefined subdirectories

The key component of the RPM package is SPECS section which contains so called spec files which are very similar to makefile.  It contains information required by RPM to build the package, as well as instructions telling RPM how to build it.  The spec files also specify what files are a part of the package, and where they should be installed. They have the ".spec" suffix and are distributed within source packages (SRPM)

It has multiple sections. Among them:

There are also several optional section

The RPM package is a binary format and consists of four sections:[1]

Working behind the scenes of the package manager is the RPM database, stored in /var/lib/rpm. It uses Berkeley DB as its back-end. It consists of a single database (Packages) containing all of the meta information of the installed rpms. Multiple databases are created for indexing purposes, replicating data to speed up queries. The database is used to keep track of all files that are changed and created when a user (using RPM) installs a package, thus enabling the user (via RPM) to reverse the changes and remove the package later. If the database gets corrupted, the index databases can be recreated with the rpm --rebuilddb  command.

To build RPMs your system should have the rpmbuild  command. (If the command "which rpmbuild" does not display anything, you don't have rpmbuild.). On Red Hat and Fedora systems, the rpmbuild  command is provided by the rpm-build  package. (You can give the command "rpm -q rpm-build" to check if it is installed.) .

It is better to use some close example (prototype RPM), especially in the source form then to build your RPM from scratch.

In this case you need first to install "prototype" RPM to your home directory. To placing the package files under $HOME/MyRPM and the rpm database in the $HOME/MyRPM/var/rpm directory use the command:

rpm -ivh --nodeps --relocate /=$HOME/MyRPM --root=/$HOME/MyRPM package.rpm

To study RPM you can also unpack it  You can do it using Midnight commander, or rom2cpio (in the latter case only content of cpio archi will be unpackaed.

# rpm2cpio emacs-common-21.4-20.el5.x86_64.rpm | cpio -idmv


The rpm2cpio command extracts a cpio archive from an RPM file, and cpio command extract files from the cpio archive.

The options used with the cpio command are described as follows.


Installing and Compiling Source Packages

All source packages of SUSE LINUX carry a .src.rpm  extension (source RPM).

The following directories must be available for rpm and rpmbuild in /usr/src/packages  (unless you specified custom settings in a file like /etc/rpmrc):

for the original sources (.tar.gz  files, etc.) and for distribution-specific adjustments (.dif  files)
for the .spec files, similar to a meta Makefile, which control the build process
all the sources are unpacked, patched, and compiled in this directory
where the completed binary packages are stored
here are the source RPMs

When you install a source package all the necessary components will be installed in /usr/src/packages: the sources and the adjustments in SOURCES  and the relevant .spec  file in SPECS.

The following example uses the wget.src.rpm  package. After installing the package with YaST, you should have the following files:


rpmbuild -b X /usr/src/packages/SPECS/wget.spec starts the compilation. X is a wild card for various stages of the build process (see the output of --help  or the RPM documentation for details). The following is merely a brief explanation:

Prepare sources in /usr/src/packages/BUILD: unpack and patch.
Do the same as -bp, but with additional compilation.
Do the same as -bp, but with additional installation of the built software. Caution: if the package does not support the BuildRoot feature, you might overwrite configuration files.
Do the same as -bi, but with the additional creation of the binary package. If the compile was successful, the binary should be in /usr/src/packages/RPMS.
Do the same as -bb, but with the additional creation of the source RPM. If the compilation was successful, the binary should be in /usr/src/packages/SRPMS.
Skip some steps.

The binary RPM created can now be installed with rpm -i or, preferably, with rpm -U. Installation with rpm makes it appear in the RPM database.

 Compiling RPM Packages with build

The danger with many packages is that unwanted files are added to the running system during the build process. To prevent this, use build, which creates a defined environment in which the package is built. To establish this chroot environment, the build script must be provided with a complete package tree. This tree can be made available on the hard disk, via NFS, or from DVD. The respective position is specified with build --rpms <path>. Unlike rpm, the build command looks for the SPEC file in the source directory. To build wget anew (like in the above example) with the DVD mounted in the system under /media/dvd, use the following commands as root:

cd /usr/src/packages/SOURCES/
mv ../SPECS/wget.spec .
build --rpms /media/dvd/suse/ wget.spec

Subsequently, a minimum environment is established at /var/tmp/build-root. The package is built in this environment. Upon completion, the resulting packages are located in /var/tmp/build-root/usr/src/packages/RPMS.

The build script offers a number of additional options. For example, cause the script to prefer your own RPMs, omit the initialization of the build environment, or limit the rpm command to one of the above-mentioned stages. Access additional information with build --help and man build.

Tools for RPM Archives and the RPM Database

Midnight Commander (mc) can display the contents of RPM archives and copy parts of them. It represents archives as virtual file systems, offering all usual menu options of Midnight Commander. Display the HEADER  with F3. View the archive structure with the cursor keys and Enter. Copy archive components with F5.

A front-end for rpm is also available for Emacs. KDE™ offers the kpackage tool. GNOME™ offers gnorpm.

Using the Alien (alien) Perl script, it is possible to convert or install an alien binary package. This tries to convert old TGZ archives to RPM before installing. This way, the RPM database can keep track of such a package after it has been installed. Beware: alien is still alpha software, according to its author — even if it already has a high version number.

Top updates

Softpanorama Switchboard
Softpanorama Search


Old News ;-)

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).

RPM Building Crash Course By Pierre Sarrazin

May 9, 2007

(See French version.)

Getting the rpmbuild command

Your system may currently have the rpm command but not the rpmbuild command. (If the command "which rpmbuild" does not display anything, you don't have rpmbuild.) On Red Hat and Fedora systems, the rpmbuild command is provided by the rpm-build RPM package. (You can give the command "rpm -q rpm-build" to check if it is installed.) Avoiding root

By default, one needs to be root to build RPM packages under the /usr/src/redhat directory. To avoid that, give the following command under root:

chown -fR someuser /usr/src/redhat

This step is only needed once. However, you can build RPM packages in any directory owned by someuser by writing an appropriate ~/.rpmmacros file. For example, put the following line in that file:

By default, RPM packages are built in the /usr/src/redhat directory, which is only writable by root. You can have the rpmbuild command use another directory (e.g., /home/your_userid/rpm) by putting this line in a file called .rpmmacros in your home directory:

%_topdir /home/your_userid/rpm

You must then create the following subdirectories in that directory:

cd /home/your_userid/rpm
mkdir -p RPMS/i386 RPMS/athlon RPMS/i486 RPMS/i586 RPMS/i686 RPMS/noarch

See the RPM reference documentation for details.

Building from a source RPM (SRPM)

Install the .src.rpm file this way:

rpm -i somepackage-1.0-1.src.rpm

This will create files in the SOURCES directory of your RPM building directory tree, and a .spec file in the SPECS directory.

Then go the SPECS directory and give the command to build the RPM:

cd /home/your_userid/rpm/SPECS
rpmbuild -bb somepackage.spec

Give the -ba option instead if you also want to build the SRPM. The binary RPM packages will typically be created in the RPMS/i386 directory (on a PC-based system).

Building from a source archive

When a source archive (e.g., somepackage-1.0.tar.gz) contains a .spec file, one can give the following command to build the RPM without having to deploy the archive:

rpmbuild -tb somepackage-1.0.tar.gz

Give the -ta option instead if you also want to build the SRPM.

(The source archives that I publish are supposed to contain a functional .spec file. If I omitted this, please complain to me.)

[Aug 10, 2004] Linux Magazine August 2004 GURU GUIDANCE Creating Custom RPMs, Part One

RPMs can be a great way to manage the packages you install on your system. Unfortunately, not everything you might want to install is available in RPM form. Perhaps you need a more recent version of a program than the one that ships with your distribution; or maybe it's a program you wrote yourself; or perhaps it's just something that's very obscure. Similar dilemmas can occur with non-program packages, such as font or clip art collections.

Whatever the case, if you're installing a program for a single computer, chances are you'll just install it the old-fashioned way, by typing make && make install (or some similar set of commands) in the source directory. make gets the job done, but it means you're giving up the benefits of the RPM system. What's more, if you're maintaining several computers, running around installing the same package on all of them can be tedious.

Life would be much easier if you could create your own RPM, giving you the ability to easily install the package on many systems and the benefits of its package tracking. Fortunately, RPM includes tools that enable you to do just that. Creating an RPM isn't as easy as creating a tarball, but the task isn't insurmountable.

This month's column covers the files and file formats involved in creating RPMs. Next month's column will present practical examples, including how to build both binary and architecture-independent RPMs.

Building RPMS from SOURCE or SRPMS

Never build RPMS as root.
  1. Log into your machine as a regular user.
  2. create a mirror image of the main RPM directory structure in your $HOME and
  3. tell RPM to use these directories instead of the original ones.

Building RPM packages as user

This document explains how to build packages without root-access. This might be useful in case you have a build environment where different users need to build packages without interfering each other.

Customizing your RPM build environment

To make RPM use your environment definitions, you need to override the default macros RPM uses. The only one that is crucial for this is %_topdir (which by default would point to /usr/src/redhat).

You can do this by adding the following to ~/.rpmmacros.

	%_topdir /home/dag/redhat/
As a consequence, RPM will need the default directory structure underneath. So you can do as user:
	mkdir -p ~/redhat/{BUILD,RPMS/{i386,i686,noarch},SOURCES,SPECS,SRPMS}

And now you're set to go.

The obvious catch
Beware that you don't have the same permissions as root, which means you can't chown files to other users. So if the default Makefile uses chown or install to change ownership, this will obviously fail. As a workaround, you can't use %makeinstall, and instead use install yourself without changing owners. Ownerships should be in the %files section.
Customize even more !
Since you now can build packages yourself, you can also customize the default packager, vendor and other information by defining more macros.
	%packager Dag Wieers <>
	%vendor Dag Wieers <>
	%_tmppath /home/dag/tmp/
	%_topdir /home/dag/redhat/
	%prefix /usr/local/

There are much more macros for changing default paths, programs or even function-macros. See our links for more specific information.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended



rpm - Trac


AAA Development-Tasks-Packaging-Tools-RPM-Howto - Mandriva Community Wiki  a very good tutorial

Red Hat Package Manager 4 information

RPM Tutorial

[] - The fight

Packaging software with RPM by Martin Streicher,

RPM HOWTO (Red Hat 1999)

Better Living Through RPM, Part 2


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 09, 2017