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:
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:
– 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 to 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:
This RPM is for the BASH shell (“/bin/bash”). The filename is composed of several parts:
[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 [version] 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).
The [version] is controlled by the original author and the [release] is controlled by whoever constructed the RPM.
Installing and Removing Files
Usually only one [version] or [release] of an RPM may be installed at once. 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 to support 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 or –install### (install new RPM; error if already installed)
rpm -U or –upgrade### (delete existing RPM, if any; install new)
rpm -F or –freshen### (update RPM only if package already installed)
rpm -e or –erase### (remove, delete, expunge)
Output: -v (verbose – file name), -h (hash)
Preconditions: –nodeps, –replacefiles, –force (BE CAREFUL HERE !!!)
Relocating: –excludepath, –prefix, –relocate, –badreloc, –root
URL Support: ftp, http
rpm -ivh binutils-22.214.171.124.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
Tips and Tricks
– 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 -q package_name
rpm -qf [filename]
rpm -qp [package filename]
default (package name)
-i: general information
-l: file list
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)
Tips and Tricks
– 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)
Many Linux distributions include a “prelink” RPM that attempts to lessen the time needed to start an application using a shared library (most applications use at least one shared library and potentially dozens) by adding special information directly into an application’s program file.
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)
Below are some RPM queries for package verifications.
rpm -import /mnt/cdrom/RPM-GPG-KEY
rpm -q gpg-pubkey
rpm –checksig m4-1.4.1-11.i386.rpm
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)