If you’ve maintained a Linux system for a while, you’ve probably noticed that you have more and more files every day, especially if you install software. And unless you have a photographic memory, you’ll probably find it difficult to remember what files go with what piece of software, especially after months or years.
In fact, the problem is worse than that. Different packages can have subtle incompatibilities with other packages, especially if they were installed months or years apart. A shared library that was installed with one package might turn out to break another package. And if this problem doesn’t show up immediately, it may well show up a few weeks later when you’ve forgotten what changes you had made.
RPM can help dramatically with these problems; under most circumstances, it seems to Do the Right Thing in a rather magical way.
RPM stands for Red Hat Package Manager, and it keeps track of the packages you install. Among other things, it:
If it sounds too good to be true, it really isn’t. Most of the time, RPM silently installs and removes packages cleanly and correctly; the rest of the time, it warns you that you are trying to do something you shouldn’t.
Examples of use
Here are a few examples that show RPM in action.
Installing a package is as simple as:
(as 'root') # rpm -i svgalib-1.2.10.rpm
This simple command installs version 1.2.10 of the package ‘svgalib’. Assuming you don’t have any version conflicts, RPM says nothing and your software is installed in the right place.
Removing a package is also simple:
# rpm -e svgalib
As long as no other RPM-installed package requires svgalib version 1.2.10, this will silently remove all the files that were installed with the previous command. (Note that you aren’t required to specify the version number! Under the reasonable assumption that you don’t have two versions of the same library installed, RPM removes the currently installed version.)
To query a package:
# rpm -q svgalib svgalib-1.2.13-3
This command tells you what version you have installed currently.
To get a list of all installed packages:
# rpm -qa [[email protected] mito]$ rpm -qa |head setup-1.9.1-2 filesystem-1.3.1-3 basesystem-4.9-2 adjtimex-1.3-3 anonftp-2.5-1 ldconfig-1.9.5-3 [...]
This command presents a list of all packages, including version numbers, that have been installed with RPM.
To find out what a package requires:
# rpm -qR glibc /sbin/ldconfig
Hmm, ‘glibc’ requires a file called /sbin/ldconfig. What else requires this file?
# rpm -q --whatrequires /sbin/ldconfig ldconfig-1.9.5-3 glibc-2.0.7-13 libtermcap-2.0.8-7 [...]
Very interesting. However, most of the time you won’t need to find out this information; most installs and removals work perfectly, and you won’t have to investigate the tangled interdependencies between the packages.
RPM has become the most widely used package manager in the Linux world, in part because it works well, and in part because it is an integral part of the popular Red Hat distribution. Because of its popularity, RPMs can be found all over the place. People who offer their own software often build RPM distributions in addition to the time-honored .tar.gz ‘tarball’ format.
The Red Hat site itself has a huge collection of RPMs; these can also likely be found on the CD that you have if you bought the commercial version of RPM.
There’s also a much larger collection of RPMs here.
When you can’t use RPM
If your Linux install is old, you might have some trouble using RPM. This is not because RPM is a new thing but because many RPMs are binary RPMs. This means that they contain software that has already been compiled.
It is possible that the software had been compiled using libraries or header files that are much newer (or older) than your own, and the binaries will not work on your system. In this case, you might have to build the software yourself and install it without the benefit of RPM; or you might be able to download a source RPM, which has many of the same features of a binary RPM but contains source code that is built on your system.ø
1. www.rpm.org The central RPM site.
Greg Travis is a freelance programmer living in New York City.