Understanding How RPM Works

How does RPM work? Each software program consists of files and directories, most of which must be located in a particular place on the filesystem. If the software program is distributed in RPM format, these files are compressed together into one RPM file along with instructions on where the files should be located on the filesystem and any additional scripts or executables that must be run before or after the files are installed. These RPM files are often referred to as packages.

A software program, such as the Firefox web browser, might consist of one RPM file. However, some programs are divided into multiple RPM files to allow the administrator to customize which parts are necessary for the system’s usage. For example, the GNOME graphical desktop is divided into many packages that contain parts of the overall desktop.

For example, the gnome-menus package contains the files necessary for the desktop menus, while gnome-panel provides the files necessary for the panels. Some GNOME packages supply additional functionality not absolutely necessary for the desktop to function properly. Dividing the desktop until these specialized packages allows the administrator to only install the software essential for each computer.

A proper RPM file should follow a specific naming convention:

<packagename>-<version>-<release>.<arch>.rpm

For example, pciutils-2.2.1-1.2.i386.rpm is the RPM filename for the 1.2 release of version 2.2.1 of the PCI utilities software package built for the i386 architecture. In our example, 2.2.1 is the version of pciutils, and 1.2 is the build version. The version number is similar to what you might have encountered with other software. The major version number is incremented when major features are added or it becomes incompatible with previous versions. It usually maps to specific package and distribution independent upstream version numbers. The minor version number is usually distribution dependent and changes for bug fixes, minor feature additions, and general maintenance. The release version starts at 1 for each version number change and is incremented every time that version is built for Red Hat Enterprise Linux. This small change allows the developer and users to know the package has been rebuilt while still keeping the version number the same.

The next part of the RPM filename is the architecture for which the package is built. Because different processors must use different software libraries, have different system calls, and utilize different optimizations, software must be built with the proper version of the compiler compatible with the architecture. There are some exceptions such as software written in an interpreted language such as Python, which is not compiled. For software written in this type of language, the correct version of the software that interprets the code must be installed while the RPM package that installs the code can be platform-independent. The most popular architectures abbreviations used by RPM are explained in Table.

System Architectures Used by RPM

Architecture	Description
noarch	Architecture-independent, can run on any architecture
i386	Generic build for a 32-bit x86 system
i586	Sometimes used when building kernels for older x86 processors
i686	Intel® Pentium® II, Intel Pentium III, Intel Pentium 4, AMD® Athlon, and AMD Duron systems (Most RPMs for these architectures are built using the i386 architecture, with the kernel for these architectures being built with the i686 for optimal performance.)
x86_64	64-bit processors such as AMD Athlon64, AMD Opteron, and Intel EM64T Intel® Itanium™
s390x	64-bit IBM eServer System z
ppc	32-bit IBM® POWER, IBM eServer™ pSeries®, and IBM eServer iSeries