Chapter 03

RPM Overview

Copyright (c) 2005 by Eric Foster-Johnson. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

In This Chapter

*	Understanding the package file

*	Querying the RPM database

*	Running RPM commands

Working with RPM packages, files, commands, and databases can be complicated. There are thousands of files, for hundreds if not thousands of packages, installed on your system. You need some way to manage it all. The RPM system can help you do that.

This chapter provides an overview of the components that make up the RPM system for package management: package files, databases, and RPM commands.

Understanding the Package File

RPM provides for installing, upgrading and removing packages. Typically, each package is an application and all the necessary files associated with that application. For example, the Apache Web server comes with a number of configuration files, a large set of documentation files, and the Apache server itself. All of this fits into one RPM package.

One of the main advantages of the RPM system is that each .rpm file holds a complete package. For example, the following file holds the xcopilot package:

xcopilot-0.6.6-3.i386.rpm

Based on the naming conventions discussed in Chapter 2, this package represents xcopilot package, version 0.6.6, third build of an RPM package, for i386 (Intel) architecture systems.

With a single command, you can copy an .rpm file to another Linux system and install it, getting the complete contents of the package, or you can use other commands to remove or update the package.

RPM file format

RPM files hold a number of tagged data items and a payload, the files to install on your system. The tagged data items describe the package and can contain optional features. For example, the NAME tag holds the package name. The optional PRE tag holds a pre-installation script, a script that the rpm command runs prior to installing the files in the package payload.

Under the covers, RPM package files contain four sections. The first is a leading identification area that marks the file as an RPM package (created with a particular version of the RPM system). The remaining sections are the signature, the tagged data (called the header), and the payload. Each of these sections has important information about the package, although the payload section contains the actual content of the package.

*	The signature appears after the lead or identifier section, which marks the file as an RPM file. Like your signature when you sign a check, the RPM signature helps verify the integrity of the package. No, the signature doesn’t check for bugs in software applications. Instead, it ensures that you have downloaded a valid RPM archive.

The signature works by performing a mathematical function on the header and archive sections of the file. The mathematical function can be an encryption process, such as PGP (Pretty Good Privacy), or a message digest in MD5 format.

*	The header contains zero or more tagged blocks of data that pertain to the package. The header contains information such as copyright messages, version numbers, and package summaries.

*	The payload section contains the actual files used in the package. These files are installed when you install the package. To save space, data in the archive section is compressed in GNU gzip format.

Once uncompressed, the data is in cpio format, which is how the rpm2cpio command (introduced in the "Other RPM commands" section later in this chapter) can do its work.

Binary RPMs and Source RPMs

There are two main types of RPM packages: binary (or applications) and source. A binary RPM has been compiled for a particular architecture. For example, the Apache Web server compiled for an Intel Pentium, or i586, architecture won’t work on a Sharp Zaurus, which runs an Intel ARM processor. To run on both systems, you would need two separate packages: one for the Pentium i586 and one for the ARM.

In addition to binary RPMs, you can get source code RPMs. These RPMs are packages that provide the source code for other packages. Sounds kind of circular, doesn’t it?

binary RPMs

Binary RPMs hold complete applications or libraries of functions compiled for a particular architecture. Most binary RPMs contain complete applications, such as the Apache Web server or the AbiWord word processor. These application binary RPMs usually depend on a number of system libraries which are, in turn, also provided by binary RPMs.

Cross Reference

Chapter 8 covers a number of locations where you can find RPM applications galore. Your Linux installation CDs are also a great source for applications. Most Linux distributions come with more applications than you can imagine using.

Although most binary RPMs are complete applications, others provide libraries. For example, the Simple DirectMedia Layer library (SDL), which provides really cool graphics for many games, can be packaged as an RPM file. A number of programs, mostly games, use this library for enhanced multimedia such as rich graphics. RPMs that provide libraries allow multiple applications to share the same library. Typically, the libraries are packaged into separate RPMs from the applications.

In addition to binary RPMs that hold applications or libraries compiled for a particular architecture, RPM supports the concept of platform-independent binary RPMs. These platform-independent RPMs, called noarch as a shorted form of “no architecture” dependencies, provide applications or libraries that are not dependent on any platform. Applications written in Perl, Python, or other scripting languages often do not depend on code compiled for a particular architecture. In addition, compiled Java applications are usually free of platform dependencies.

Source RPMs

The xcopilot package, mentioned previously, contains the xcopilot application used for synchronization with Palm handheld devices. The source code used to create this application is stored in an xcopilot source RPM, for example:

xcopilot-0.6.6-3.src.rpm

By convention, source RPMs have a file name ending in .src.rpm.

Source RPMs should contain all the commands, usually in scripts, necessary

to recreate the binary RPM. Having a source RPM means that you can recreate the binary RPM at any time. This is a very important goal of the RPM system.

Note

Source RPMs have nothing to do with open-source software licenses. Linux is famous for being an open-source operating system. In RPM terms, that means the source code for the Linux kernel and most Linux applications are freely available as source RPMs. But you can also make source RPMs for proprietary programs. The key issue is that you are unlikely to distribute the source RPMs for proprietary packages.

Furthermore, a number of open-source applications are not available as source RPMs. That's a shame, since source RPMs would make these applications easier to install.

While source RPMs hold the commands necessary to create the binary RPM, there may be differences in your Linux environment that would result in rebuilding a binary RPM that is different from the original binary RPM. For example, the compile scripts for some packages may add in optional code depending on which libraries or which versions of libraries are found on your system. Chapter 14 covers many issues in creating RPMs, and Chapters 19 and 20 cover issues related to other versions of Linux and other operating systems, respectively. If you follow the guidelines when making your own RPMs, you should result in source RPMs that reproduce binary RPMs as consistently as possible.

Querying the RPM Database

The RPM database holds information about all the RPM packages installed on your system. You can use this database to query what is installed, to help determine if you have the latest versions of software, and to verify that your system is properly set up, at least from a packaging point of view.

The RPM database itself is stored in the directory /var/lib/rpm, and should contain files like the following:

Basenames

Conflictname

__db.001

__db.002

__db.003

Dirnames

Filemd5s

Group

Installtid

Name

Packages

Providename

Provideversion

Pubkeys

Requirename

Requireversion

Sha1header

Sigmd5

Triggername

Cross-reference

Chapter 5 covers the database in more detail.

These files make up the RPM database. The file __db.001 and similar files are lock files used by the RPM system. The other files are databases in Berkeley DB format. The most important file is Packages. The Packages file contains the header tag information for each package indexed by an index number for each package. This number slowly grows with time.

The other files, such as Name, Providename, and Group, exist to speed access to particular types of information. Treat your RPM database with care. Back up the files, especially after upgrading, installing, or removing packages.

Note

Only the Packages file is essential. You can recreate the rest of the files using the rpm --rebuilddb command, introduced in Chapter 5.

Running RPM Commands

The primary RPM command is simply rpm. One of the original goals of the RPM system is providing ease of use. In support of this goal, just about everything you want to do with the RPM system can be done with this one command. For most usage, the command-line parameters to the rpm command determine the actions it should take.

Working with the rpm command

The rpm command performs the most common package-management functions, along with a host of uncommon functions as well. Table 3-1 lists the main operations you can perform with the rpm command and the command-line options to specify the given operations.

Table 3-1 The main rpm operations

Operation	Short Option	Long Option
Upgrade/install	-U	--upgrade
Install	-I	--install
Remove	-e	--erase
Query	-q	--query
Verify	-V	--verify
Check signature	-K	--checksig
Freshen (upgrade) already-installed package	-F	--freshen
Initialize database	None	--initdb
Rebuild database	None	--rebuilddb

Using Table 3-1 as a guide, you can explore the options to the rpm command. To install or upgrade a package, use the -U command-line option:

# rpm -U filename.rpm

For example, to install the xcopilot RPM used as an example in this chapter,

run the following command:

# rpm -U xcopilot-0.6.6-3.i386.rpm

To get extra feedback, you can use a command like the following, with the

-h and -v options in conjunction with the –U option:

# rpm -Uhv xcopilot-0.6.6-3.i386.rpm

When you run this command you will see more output than the default, which is no output unless there are errors. With the –h option, the rpm command will print a series of hash marks, #, to provide feedback that the command is still running. With the –v option, the rpm command provides more verbose messages.

Note

The most common command to install a package is:

# rpm -Uhv package_file.rpm

This command upgrades a package with extra output. If the package has not been installed, this command installs the package. See Chapter 4 for more on upgrading and installing.

To remove a package (called erase in RPM terminology), use the –e command-line option:

# rpm –e package_name

Note

Notice that you install a package file using the file name that ends in .rpm, but uninstall or erase a package without the .rpm extension. This is because you install RPM files, but once installed, you work with the installed packages. The file name and the package name do not have to correspond, but typically (and sanely) they have the same base name.

To list every RPM package installed on your system, use a command like the following.

$ rpm –qa

Expect to wait while this command completes. Most Linux systems have numerous packages installed, which will result in many lines of output. To better see the output, you can pipe this command to the more command, as shown following:

rpm –qa | more

You will then see the package listing one screen at a time.

Cross Reference

Appendix A lists all the options for the rpm command.

Other RPM commands

In addition to rpm, the RPM system includes a few more commands, including rpmbuild and rpm2cpio.

The rpmbuild command helps build RPM packages. I describe its usage in depth in Part II of this book.

The rpm2cpio command exports an RPM package file into the format that the cpio command expects. The cpio command works with many tape-backup packages. You can also take advantage of the fact that cpio can list the individual files in a cpio archive or extract files. To list the files in an RPM package, use a command like the following:

$ rpm2cpio package_file.rpm | cpio –t

For example, the following command lists all the files in the xcopilot package:

$ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio –t

/etc/X11/applink/Applications/xcopilot.desktop

usr/bin/xcopilot

usr/doc/xcopilot-0.6.6

usr/doc/xcopilot-0.6.6/README

usr/include/X11/pixmaps/xcopilot.xpm

usr/include/X11/pixmaps/xcopilot2.xpm

3120 blocks

The rpm2cpio command can also help if you want to extract a single file from the RPM package, using the cpio –ivd command-line options, as follows:

$ rpm2cpio xcopilot-0.6.6-3.i386.rpm | cpio –ivd usr/doc/xcopilot-0.6.6/README

This command will output local usr/doc/xcopilot-0.6.6 subdirectories and the README file located under usr/doc/xcopilot-0.6.6.

The –i option tells cpio to extract files. The –d option tells cpio to make any local subdirectories as needed (usr/doc/xcopilot-0.6.6, in this example), and the –v option asks cpio to politely output verbose messages about what it does. Of course, verbose is in the eye of the beholder; with many Unix and Linux commands, verbose output is still somewhat terse.

Summary

The RPM files, the RPM database, and the RPM commands are the primary components that make up the RPM system. This chapter introduces you to the format and types of RPM files, the importance of maintaining the database, and the basic rpm command.

The next chapter covers the most frequently used RPM commands. These commands allow you to install, uninstall, and update RPM packages.

Chapter 03

Chris Ricker

2003-01-17T12:19:00

Eric Foster-Johnson