RPM Package Manager

Encyclopedia : R : RP : RPM : RPM Package Manager

The RPM Logo

RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) in the context of package management refers to two things: a software package file format, and the original tool developed to manage those packages. RPM was intended primarily for Linux. The package management tool RPM installs, updates, uninstalls, verifies and queries software. The file format RPM is the baseline package format of the Linux Standard Base.

Originally developed by Red Hat for Red Hat Linux, RPM is now used by many Linux distributions. It has also been ported to some other operating systems such as Novell NetWare (since version 6.5 SP3) and IBM AIX since version 5, see [RPM homepage] for all supported platforms.

"RPM", as it is used today, is an example of a recursive acronym.

Contents

1 The file format
2 The RPM database
3 Package label
4 Advantages and disadvantages of the format
5 Creating RPMs
6 Examples
7 Supported Linux distributions
8 Related tools
9 External references and links

The file format

The RPM database

Working behind the scenes of package manager is the RPM database, stored in /var/lib/rpm. It consists of a single database (Packages) containing all of the meta information of the installed rpms and multiple databases used for indexing purposes. The database is used to keep track of all files that are changed and created when a user installs a program and thus allows rpm to remove packages. If the database gets corrupted (which happens easily if the RPM client is killed), the index databases can be recreated with the rpm --rebuilddb command.

Package label

Every RPM package has a package label, which contains the following pieces of information:

the software name
the software version (the version taken from original "upstream" source of the software)
the package release (the number of times the package has been rebuilt using the same version of the software) this field is also often used for indicating the specific distribution the package is intended for by appending strings like "mdk" (Mandriva Linux), "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
the architecture the package was built under (i386, i686, athlon, ppc, etc.)

and the RPM file would normally have the following format:

--..rpm

An example:

nano-0.98-2.i386.rpm

However, note that 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.:

libgnomeuimm2.0-2.0.0-3.src.rpm

Additionally, libraries are distributed in two separate packages for each version. One containing the precompiled code and one containing the development files such as header files etc. for the library in question. Those packages have "-devel" appended to their name field. Users need to carefully check so that the version of the development package matches that of the binary package, otherwise the library may very well not work.

RPM files with the noarch.rpm extension refer to files which do not depend on a certain computer's architecture. These files usually include graphics and text for another program to use.

Advantages and disadvantages of the format

Advantages of using RPM packages over other ways to acquire and install software often cited are:

A uniform way for the user to install programs.
Simple to uninstall programs.
Popularity: lot of packages available, even though they often need recompilation to work in another distribution.
Non-interactive installation: makes it easy to automate installation.
Original source archive (e.g. .tar.gz, .tar.bz2) included: easy to verify.
Cryptographic verification with GPG and md5.
DeltaRPMs, which are RPM's equivalent of a patch file, combine themselves with installed RPMs to perform updates on software that was installed by RPM. This is a much more convenient way to update RPM-installed software, since DeltaRPM doesn't require the original package to perform the update.

Disadvantages often cited include:

Often has backwards incompatible changes in package format.
Incomplete and outdated documentation.
Packaging typically has a steep learning curve.
Sometimes contradictory package version dependencies, varying by which Linux distribution is using RPM.
Cannot be unpacked with ordinary tools like deb and tgz packages (though the rpm source tarball includes a shell script - rpm2cpio.sh[link] - that extracts the cpio archive part from an rpm using only od, expr, dd and gunzip).
Per-file dependencies, rather than per-package dependencies. This compounds the issue stated below.

RPM has also been criticized for a lack of consistency in package names and content, which can make automatic dependency handling difficult. However, this is not a problem inherent in the RPM format, but rather a problem of co-ordination amongst major distributions who use RPM in packaging such as Red Hat Linux, SUSE, and Mandriva Linux. When using packages that are from a particular distribution (say Red Hat Linux) or built for a particular distribution (for example Freshrpms [link] for Red Hat Linux), then automatic dependency checking can work, using tools such as yum or apt (see below). A tool exclusively for Mandriva Linux is urpmi, and can help with the so called 'dependency hell'.

Creating RPMs

The "recipe" for creating an RPM package is a spec file. Spec files end in the ".spec" extension and contain the package name, version, RPM revision number, steps to build, install, and clean a package, and a changelog. Multiple packages can be built from a single RPM spec file, if desired. RPM packages are created from RPM spec files using the rpmbuild tool.

Examples

rpm -qa --queryformat '%010\t%-%-%\n' lists the installation size of all installed packages.

Supported Linux distributions

Several Linux distributions support RPM. These include, but are not limited to:

(See also: List of Linux distributions.)

Related tools

There are several front ends to RPM that resolve dependencies.

The best-known ones are:

YaST used in SuSE
urpmi used in Mandriva Linux
yum used in Yellow Dog Linux and Fedora Core.
apt4rpm, a port of Debian's Advanced Packaging Tool (APT) whose use is recommended by some Fedora repositories. It is less actively developed but generally uses fewer CPU cycles than the above.
smart available for many distributions

External references and links

Eric Foster-Johnson, 2003, Red Hat RPM Guide. ISBN 0764549650. A complete, up to date (as of 2003) guide for building RPM packages.
Fox, Pennington, Red Hat 2003: Fedora Project Developer's Guide: [Chapter 4. Building RPM Packages]
[RPM man page]
[RPM Package Manager homepage]
[RPM Building as a User]
Bailey, Ed 2000: [Maximum RPM], an outdated but popular rpm reference
[SUSE Package Conventions]
[Package File Format - Linux Standards Base]
[A repository of RPMs for a wide (if sometimes outdated) variety of operating systems]
[A mailing list post containing a copy of rpm2cpio.sh to allow extraction of rpms with standard UNIX tools]

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.