Maintaining Software Using RPM (Red Hat Package Manager)
RPM is a powerful software manager which can be used to build, install, query, verify, update, and uninstall individual software packages. An RPM package consists of an archive of files, and package information such as name, version, a description and information about dependencies on other RPM packages.
RPM is more than a Red Hat specific tool. Many other modern distributions, such as Ubuntu and SuSE, use RPM too. Benefits of using RPM include:
- Simplified software distribution, installation, upgrading and removal
- Guarantees that:
- prerequisite software is installed on system.
- versions of prerequisite software stay compatible.
- locally-modified configuration files are not clobbed when the RPM is updated.
- locally-modified configuration files are saved with an “.rpmsave” suffix if the package is later deleted.
- Allows certification that installed software has not been altered, modified, corrupted, or changed in any way.
RPM keeps information about installed packages under the “/var/lib/rpm” directory.
Components of the RPM tool are:
- A custom database containing information about all software installed on the system, collected from the individual RPMs.
- A “/bin/rpm” executable.
- Internet-accessible repositories of available RPM packages.
Types of RPM Packages
RPM packages come in two categories: source and binary.
A source RPM can always be recognized because the filename ends with the string “.src.rpm“. In a source RPM are not only the original program source code files but scripts that allow the code to be recompiled automatically, to be installed automatically, and to be removed automatically. There are no end-user executable files in a source RPM. Usually, only developers are interested in a source RPM.
A binary RPM contains the end-user compoments of an RPM. Binary RPM filenames identify the host architecture for the contents. For example, the binary RPM file:
bash-3.1-16.1.x86_64.rpm
It contains files only usable on a 64-bit Intel X86 architecture CPU. Other common architecture values include “i386” for 32-bit Intel hosts. Some binary RPM’s may be installed on any CPU architecture because their files will work on any host; an example of these “.noarch.rpm” packages is the “tzdata” RPM which contains information about world timezones. To update your system with the latest version of a package, you will need the most recent binary RPM for it.
RPM Naming Scheme
Each RPM package is contained in a single file. The filename has several fields to fully identify the contents of the package. While the RPM tools themselves do not rely upon the filename itself, you should understand the filename convention to help you identify or download the proper package. Here is an example RPM filename:
bash-3.1-16.1.x86_64.rpm
This RPM is for the BASH shell (“/bin/bash”). The filename is composed of several parts:
[name]-[version]-[release].[arch].rpm
where:
- [name] is the name of the program or package. The [name] is usually assigned by the program’s author. In our example, the developers decided to name their product “bash” for reasons that seemed amusing to them.
- version] identifies which edition of the software this RPM contains. The [version] number is assigned by the program’s author. Using the number allows one to determine which version of the author’s sources were used to generate the RPM.
- [release] provides the edition number of the RPM file itself and not the version of the author’s source files. An updated RPM may be issued to supply a patched version of the author’s original software. The patch need not have come from the original developer, so the RPM [release] gets incremented instead of the [version].
- [arch] describes the contents of the RPM and tells whether this file contains the product source (a “.src.rpm”), architecture-independent files (a “.noarch.rpm”), or files which may only be installed on a particular host type (a “.sh.rpm” will work only on a STRONGHOLD embedded processor).
Understanding RPM Versions
The RPM [version] and [release] fields are not always strictly numeric and may contain other characters besides ordinary digits. It is common to see both a version “10” and a “10a” version of the same package. Sometimes picking the most recent version can be tricky. Here is how RPM itself compares version and release numbers internally:
1. Remove the [name] prefix and the “.[arch].rpm” suffix. For example,:
“bash-3.1-16.1.x86_64.rpm” becomes “3.1-16.1” and “bash-3.1-16.5a.1.x86_64.rpm” becomes “3.1-16.5a.1”
2. Compare the remaining strings character-by-character, left-to-right until a digit is encountered. If the characters differ, whichever character comes later in the collating sequence is the more recent RPM.
3. When a digit is encountered, convert the entire sequence of digits into a single binary number. In our example, the two characters “16” are combined into a value of sixteen (16). The resulting binary values are compared and the greater value is the more recent RPM. Thus, an RPM with a [version] of “0010” is more recent than one with a [version] of “9”.
Steps 2 and 3 are repeated as necessary until a difference occurs.
Installing and Removing Files
Later versions are usually installed using the “-U” (update) RPM function instead of the “-i” RPM function. Common exceptions to the only-one RPM rule are the kernel RPM’s. A system commonly has several versions of kernels installed; RPM has a list of which RPM’s may have multiple versions installed. To delete one version when several are installed, you must fully-specify the package name and version.
On the x86_64 architecture, it is common to have both the 32-bit “.i386” and the 64-bit “.x86_64” RPM packages installed tosupport both 32-bit and 64-bit applications. Normally, RPM does not display the architecture of a package on a query but you can manually display it.
Installation and Removal
# rpm -i --install (install new RPM; error if already installed) # rpm -U --upgrade (delete existing RPM, if any; install new) # rpm -F --freshen (update RPM only if package already installed) # rpm -e --erase (remove, delete, expunge)
Common Options
Output: -v (verbose – file name), -h (hash)
Preconditions: –nodeps, –replacefiles, –force (BE CAREFUL HERE !!!)
Relocating: –excludepath, –prefix, –relocate, –badreloc, –root
URL Support: ftp, http
Examples:
# rpm -ivh binutils-2.11.90.0.8-12.i386.rpm # rpm -Uvh finger-0.17-9-i386.rpm # rpm -Fvh ftp://updates.redhat.com/current/i386/*.rpm # rpm -e diffutils # rpm -e kernel-enterprise-2.4.9-e.12
Hint: Never, ever, use the “-U” option to install a new kernel RPM. The “-U” update function first deletes the current RPM from the system and then attempts to install the new RPM. Any problem that prevents the new RPM from installing will leave the system unbootable. This is not what you want, so always use the “-i” switch to install a kernel RPM.
Queries (Packages and/or Information)
Use a query for information about installed packages. You may query against all installed packages, or a single installed package. You may also find out which RPM supplies a particular file.
# rpm -q [packages] [information] # rpm -qa (all installed packages) # rpm -q package_name # rpm -qf (filename) # rpm -qp (package filename)
Information
default (package name)
-i: general information
-l: file list
Examples:
# rpm -qa # rpm -q kernel -i (information) # rpm -q kernel -l (files contained in package) # rpm -q kernel --requires (prereqs) # rpm -q kernel --provides (capabilities provided by package) # rpm -q kernel --scripts (scripts run during installation and removal) # rpm -q kernel --changelog (revision history) # rpm -q kernel -queryformat format (rpm --querytags for list of options)
Hint: When searching for a particular RPM package when the exact name is not known, a command pipeline such as:
$ rpm -qa | grep foo
is commonly used. Later versions of the RPM tool allow this to be succinctly done as:
$ rpm -qa '*foo*'
Queries – Verification (Files)
The RPM database contains many attributes about each and every file installed by an RPM. You may verify the current status of the file against the information cataloged by RPM when the package was installed.
# rpm -V package_name # rpm -Va (verify all) # rpm -Vf (filename) # rpm -Vp (package filename)
Adding this information does make applications start faster, but the file changes invalidate most of the file attributes in the RPM database, such as the last file modification date, file size, and the file’s MD5 checksum.
Queries – Verification (Packages)
# rpm -import /mnt/cdrom/RPM-GPG-KEY # rpm -q gpg-pubkey # rpm --checksig m4-1.4.1-11.i386.rpm
Examples:
# rpm -qf /path/filename (what package owns filename) # rpm -qf /path/filename -i (what does it do) # rpm -qp m4-1.4.1-11.i386.rpm -l (files in m4) # rpm -qp m4-1.4.1-11.i386.rpm --requires (prereqs needed to install m4) # rpm -q --whatprovides glibc.so (what package provides requisite library)
Repair the RPM database
The RPM tool uses its own custom database implementation to contain its information. Sometimes that database can get corrupted; symptoms include claims that an installed RPM package is missing; or attempts to update an RPM simply hang. If your RPM database is hung or corrupted you can try to repair it with these commands. This process is not guaranteed to work.
You must be logged in with superuser privilege (aka “root”) for these steps. The commands may be copied and pasted directly into a root terminal window.
1. Make sure there are no RPM processes left running on your system. Use the ps command to identify them. Use the kill command to terminate any “rpm” processes you find; a “kill -9” may be necessary.
2. Delete the lock files that RPM uses:
# rm -f /var/lib/rpm/__db*
3. If you were experiencing a hanging “rpm” command, try it again. If it works, you are finished. If not, perform Step #1 and #2 again. Then proceed to the next step.
4. Make a backup of your RPM database:
# cd /var/lib # mkdir rpm-backup # rsync -av ./rpm/. ./rpm-backup/.
5. Rebuild your RPM database:
# rpm -vv --rebuilddb > /tmp/rpmrebuilddb.log 2>&1
6. Retry your failed RPM command.