MandrakeUser.Org - Your Mandrake-Linux Knowledge Base!


* DocIndex - Basics


* What Is RPM?
* What RPM Does For You
* What RPM Does Not Do For You

Related Resources:

An Introduction to Package Management

Revision / Modified: Mar. 14, 2002
Author: Tom Berger


* What Is RPM?

RPM is short for Red Hat Package Manager. First used by the Red Hat Linux distribution (obviously ;)), it is now the package format of choice for most major distributors: SuSE, Caldera, Conectiva and - of course - Mandrakesoft, to name a few.

What is a 'package', then? A package is an archive: it contains all the files which belong to a certain application, program library or whatever the package name indicates. Think of an ZIP or an TAR archive. But apart from this (compressed) archive, the package also contains control scripts. These control scripts are read, executed and stored by the local RPM installation and handle things like installation, deinstallation, status checking, dependencies etc.
Packages are built by package maintainers using a so-called 'specfile' (specification file) which determines where the files of a package are going to be installed to, which other packages are needed by the package in order to work correctly, what programs to execute before or after installing or uninstalling a package, but also information on who built the package and when, a description of the purpose of the content of the package and much more.

In order to work efficiently, RPM needs to keep track of which packages are installed on a system. This database is located in '/var/lib/rpm'. As you will see, this database also allows you to extract lots of useful information about installed programs.

* section index * top

* What RPM Does For You

Among the things RPM and the package maintainer do for you are:

  • Compiling and patching the program's source code. This is convenient especially for new users. Compiling source code and applying patches requires some advanced knowledge, although it's by no means black magic. But even if you know enough to compile sources on your own, RPM comes in handy when you just can't be bothered with compiling or the sources are large or known to be tricky to handle.

  • Handling dependencies. In contrast to monolithic operating systems like Windows, Linux systems can differ from each other pretty much depending on installation size, intended use of system, personal preferences of the user etc.
    Now instead of equipping all Linux systems with all the necessary files, you select the files, programs, program libraries you want. When you are about to install a new program, RPM will check if you've got everything installed needed to run the program successfully. And what's even more important, it will prevent you from accidentally removing packages which are essential for other packages or even your system as a whole.

  • Providing information on file status. RPM provides you with many possibilities to inquire the status of packages, be they installed or not. You can check new packages for integrity before you install them and check afterward if they have been installed correctly. You can find out which package has been installed when, how much space it takes up, which documentation or configuration files are included, recent changes applied to the package by the package maintainer and more.

  • Security checks. RPM provides a mechanism to sign packages with a PGP or GPG signature. This way you can make sure that the package has not been tampered with.

  • Automation. RPM can and is used in many scripts to automate maintenance tasks. It also provides the sound foundation for graphical RPM tools and extensions like 'rpmfind' or Mandrake Linux' own 'urpmi' system.

  • Clean removal. It just takes one command to remove an RPM from your system. This command will remove everything except for files changed during the installation time of the package (usually configuration or spool files).

  • Preserve configuration files. The package maintainer can decide how to handle configuration files of older package versions. He can either leave them in place and create the new versions as 'rpmnew' files, or he tells RPM to rename the old configuration files to 'rpmsave' files and put the new versions in their place.

  • Discrimination between runtime and compile time files. Packages containing program libraries are split in runtime and compile time ('devel') packages. If you don't compile source yourself, you don't need to install the 'devel' packages. Or you can install them when you want to compile some software and remove them again afterward.

  • Network capability. It doesn't matter to RPM if the packages it is told to operate on are on a local file system, an NFS mount or an FTP server, as long as you provide the full path to the file(s).

  • Easy rebuilding. Every RPM containing Free or Open Source software stems from a 'Source RPM' (aka SRPM or 'src.rpm'). This SRPM contains everything which is needed to build the related RPM(s).
    This can be useful if you want to use different compile time options or simply adept the package to your specific system environment (release, kernel version, library versions etc), without getting the source yourself, applying all the needed patches and so forth.

* section index * top

* What RPM Does Not Do For You

Like every tool, RPM has its limitations:

  • No automatic resolution of dependencies. RPM will tell you what's missing, but it won't fetch and install it for you. This major limitation can be - at least partly - overcome by using extension tools like Mandrake Linux' 'urpmi' or the generic 'rpmfind' script.

  • No interactive configuration. Vendor supplied packages usually contain adapted configuration files and post-installation scripts. Interactive configuration steps however must be taken separately from installation (if needed).

  • No protection from packaging errors. We all make mistakes, and package maintainers are no exception. Incorrect specfiles can prevent a packaged program from running properly after installation. In theory it is even possible to use RPM to intentionally damage a system (since installation has to be done as 'root'). Therefore you should only use packages from trusted parties.

  • No compatibility guarantee. RPM is used by many Linux distributors and independent persons. Different packaging policies might prevent a package either from installing or the included program from running after installation (e.g. by putting the executable in a different directory than your distribution). Prefer packages from your distributor to those of others.

  • Optimizations. It is possible to optimize RPMs for a certain type of processor by compiling the program sources with the appropriate options. Mandrake Linux does that for the Pentium-class (i586) of processors.
    But these compiler options are just one part on a vast array of available compiling settings.
    Usually the packager will try to enable as much options as possible, which results in bigger - and sometimes slower - executables and big packages with lots of files. Bottom line: if you want fine tuning, you have to compile the sources yourself.

Although RPM is by no means perfect, it is a very versatile tool, all the more when used in conjunction with extensions like 'urpmi'.

* section index * top

* Basic RPM Handling

Legal: All texts on this site are covered by the GNU Free Documentation License. Standard disclaimers of warranty apply. Copyright LSTB (Tom Berger) and Mandrakesoft 1999-2002.