Product SiteDocumentation Site

RPM Terminology

When working with RPM, understanding the package concept is key. RPM packages are provided as compressed archive files that contain one or more files, as well as instructions specifying installation information about those files, including the ownerships and permissions that should be applied to each file during installation. The instructions can also contain scripts to be run after installation or before uninstallation. These package files are extremely convenient; they provide a single file that can be easily transferred between machines for installation rather than having to transfer each file to be installed.
To help in installation and management, all package files are labeled with highly identifiable names. Package files have four-part names, which typically look something like:
Here, the four parts of each name are separated from each other by dashes or periods. The structure of the package file name is
name-version-release.architecture.rpm
The name identifies what software is contained within the archive file. Typically, this is a name of an application or package that the archive installs on the system. For example, kernel-smp can be installed to provide a very important application, the SMP (symmetric multiprocessing, meaning it supports systems with more than one CPU in them) version of the Linux kernel, on the system. Sometimes, rather than an application, the software is a collection of other files needed on the system. The rootfiles package, for example, is not an application but is a collection of basic environmental configuration files for the root user's account (such as /root/.bashrc, the root user's Bash configuration file) that provides a usable, preconfigured working environment for the root user.
The second field in every package file's name is the version field. This field identifies the version number of the software that is contained in the package file. For example, kernel-smp-2.6.32.9 indicates the RPM holds the 2.6.32.9 release of the SMP version of the Linux kernel, and rootfiles-7.2 is the 7.2 release of the rootfiles configuration files.
Every package file name also has a third component: the release field. This field identifies which release of that version of the software the package file contains. Package files contain both software and instructions about how to install that software. As packages of a particular version of software are being prepared, mistakes are sometimes made in these instruction files, or bugs are sometimes fixed within a software version; more recent package files of that software version need to be prepared that correct the problem. The –1 in the rootfiles-7.2-1 package shows this is the first release of the 7.2 version of the rootfiles software. The packager of rootfiles version 7.2 got everything right on the first try and had no need to prepare more than one release. The –3 in the kernel-smp-2.6.32.9-3 package, on the other hand, is the third release of the 2.6.32.9 version of the SMP-capable Linux kernel. This release incorporates new patches to fix bugs present in older releases of the 2.6.32.9 version of the Linux SMP kernel. The software packager increased the release number so that end users could distinguish the more recent, bug-fixed package file from the older, less bug-free package file.
The final field in package file names is the architecture, which identifies the system types for which the package file is appropriate. For example, the kernel-smp-2.6.32.9-3.x86_64 package is intended for use on machines with a 64-bit CPU, and kernel-smp-2.6.32-9-3.i686 is intended for use on machines with an i686 (Pentium-class) CPU or better. An architecture name of noarch indicates this is a special architecture such that the files in the package work on any architecture. Typically, this is because the files are all interpreted scripts, not binary executables, or are documentation.
RPM supports various architectures. Table 2-1 presents the architectures available for different platforms as of RPM version 4.7.
Table 2-1 Supported Architectures
Platform
Architectures
Intel-compatible 32-bit
i386, i486, i586, i686, athlon, geode, pentium3, pentium4
Intel-compatible 64-bit
x86_64, amd64
Intel Itanium
ia64
HPAlpha (formerly Digital, Compaq)
alpha, alphaev5, alphaev56, alphapca56, alphaev6, alphaev67
Sparc/Ultra Sparc (Sun)
sparc, sparcv8, sparcv9, sparc64, sparc64v, sun4, sun4c, sun4d, sun4m, sun4u,
ARM
armv3l, armv4b, armv4l, armv5tel, armv5tejl, armv6l,armv7l
MIPS
mips, mipsel
Power PC
ppc, ppciseries, ppcpseries, ppc64, ppc8260, ppc8560, ppc32dy4
Motorola 68000 series
m68k, m68kmint, atarist, atariste, ataritt, falcon, atariclone, milan, hades
SGI MIPS
Sgi
IBM RS6000
rs6000
IBM S/390
i370, s390x, s390
Platform independent
noarch

Architecture Compatibility

When choosing an appropriate architecture for your machine, be aware that more recent architectures typically run software that targets older architectures within the same family; the reverse, however, is not true. For example, within the 32-bit Intel-compatible architectures, a 686-class (Pentium II / III / IV) machine runs files within i386, i486, i586, and i686 RPM package files, but a 386-class (80386) machine runs files within i386 RPM package files only. Similarly, for the Alpha architecture, more recent Alpha EV68 CPUs can run programs from RPM package files with alphaev67, alphaev6, alphaev56, alphaev5, and alpha architectures, but an older Alpha EV56 machine can run programs from RPM package files with alpha, alphaev5, or alphaev56 architectures only.
Notice that the four fields in RPM package file names are separated from each other by punctuation, either a dash (-) or a period (.). Periods and dashes, however, are also allowed within fields. 7.2 is a valid version number, just as kernel-source is a valid software name. Finally, keep in mind that all RPM package files use an .rpm file-name extension to denote that they are RPMs.
Once installed, package names are slightly different from package file names. Package files, which can be downloaded from the Internet, copied off of CDs, and otherwise easily transferred between machines, always have names that looks like name-version-release.architecture.rpm. Installed packages, however, have names that look like name-version-release. Once installed, packages are referred to without the architecture field and the .rpm extension. Furthermore, installed packages consist of lots of files, not a single RPM file. For example, the package file kernel-smp-2.6.32.9-3.i686.rpm after installation is referred to as kernel-smp-2.6.32.9-3. To simplify usage even further, installed packages can be referred to by their name field only, so this file would become simply kernel-smp.

Software Names May Differ from Package Names

Once installed, the name of the package does not have to be the same as the name portion of the original package file. By convention though, the package name matches the name, version, and release part of the file name.
Usage of the name field by itself to name packages assumes that multiple versions or releases of that particular software are not installed. However, it is in some cases necessary to install different versions or releases of the same package. My desktop at home is a 64-bit AMD system. On it, I have the following Linux kernels installed:
This example uses the rpm –q command to query for all installed versions of the given package, kernel.

The RPM Database

Chapter 4, Using the RPM Database covers querying the RPM database in depth.
I have three different versions installed on this system. Since I have multiple packages installed of the kernel software, I have to use the full package name (such as kernel-2.6.32.11-99) whenever I want to work with my installed kernel packages.