Understanding the rpm Utility

Basic RPM functionality resides in the rpm utility, which has the following syntax: rpm operation [options] [package-names \ package-filenames]

Table 11.1 summarizes the most common and important rpm operations, while Table 11.2 summarizes some common and important rpm options. Every rpm command requires one operation and often has one or more options. In most cases, you can specify multiple package names or package filenames. These two types of names are distinct. A package name is the name used by the package in the package database; it doesn't need to bear any resemblance to the filename used to store the package prior to installation, although in most cases the two are related. Recent versions of RPM support directly retrieving packages via the File Transfer Protocol (FTP) or from websites, so a package filename can be a URL; or it can be an ordinary local filename.

Table 11.1: Common rpm Operations

rpm Operation



Installs a package; the system must not contain a package of the same name.


Installs a new package or upgrades an existing one.

-F or-freshen

Upgrades a package only if an earlier version already exists.


Queries a package: Determines if a package is installed, what files it contains, and so on.

-V or-y or-verify

Verifies a package: Checks that its files are present and unchanged since installation.


Uninstalls a package.


Builds a binary package, given source code and configuration files. Split off into rpmbuild program as of RPM 4.1.


Builds a binary package, given a source RPM file. Split off into rpmbuild program as of RPM 4.1.


Rebuilds the RPM database, to fix errors.

Table 11.2: Common rpm Options

rpm Option

Used with Operations


-root dir


Modifies the Linux system having a root directory located at dir. This option can be used to maintain one Linux installation discrete from another one, say during OS installation or emergency maintenance.



Forces installation of a package even when it means overwriting existing files or packages.

-h or-hash


Displays a series of pound signs (#) to indicate the progress of the operation.


-i, -U, -F

Used in conjunction with the -h option to produce a uniform number of hash marks for each package.


-i, -U, -F, -e

Performs no dependency checks. Installs or removes the package even if it relies on a package or file that's not present or is required by a package that's not being uninstalled.



Check for dependencies, conflicts, and other problems without actually installing the package.

-prefix path


Sets the installation directory to path for relocatable packages. (Used with the -q operation, reports whether or not the package is relocatable.)

-a or-all


Queries or verifies all packages.

rpm Option

Used with Operations


-f file or—file file


Queries or verifies the package that owns file.

-p package-file


Queries the uninstalled RPM package-file.



Displays package information, including the package maintainer, a short description, and so on.

-R or-requires


Displays the packages and files upon which this one depends.

-I or—list


Displays the files contained in the package.

In most cases, the package filename takes the format packagename-version-revision.arch.rpm, as in manydep-2.31-6mdk.i586.rpm. The version is the official version number of the original program, such as 2.31 in this example. This version number corresponds to a release of the program from its official maintainer. The revision number refers to minor changes made to the official release to enhance it or add distribution-specific features. For instance, this number might go up if the package maintainer alters a configuration file default or applies a patch to fix a bug. Many distributions include a code to identify their distribution in this number, as in 6mdk for revision 6 from Mandrake. The arch in the filename is a CPU architecture code, such as ¡386 or ¡586 for IA-32 systems with varying CPU optimizations, or ppc for PowerPC. The noarch code stands for an architecture-independent package, such as fonts or a set of scripts. Source packages are identified by src architecture codes. A few SuSE packages use the nosrc architecture code, indicating a binary package for which a source package isn't available.

0 0

Post a comment