RPM Guide

Perhaps the primary design goal for RPM is that it must be easy to use. Manual software installation has been the primary method of putting software onto Unix boxes for over 30 years now and has worked very well for those three decades. To offer a compelling reason to use the new software, RPM must be significantly easier to use than other Linux package-management tools. For that reason, most tasks that can be handled using RPM were designed to be carried out via a single command. For example, software installation using RPM requires a single command (rpm -U software_package), while manual software installation using older manual methods typically requires at least six steps to complete the same task:

Similarly, removal of applications installed using RPM requires a single command (rpm -e software_package); manual removal of an installed application requires that each file associated with that application be manually deleted.

Like its predecessors, RPM is intended to operate on a package level. Rather than operating on a single-file basis (as when you manually install software using Unix command-line tools like mv and cp) or on an entire system basis (as with many PC operating systems, which provide the ability to upgrade entire releases but not to upgrade individual components), RPM provides software that can manage hundreds or thousands of packages.

Each package is a discrete bundle of related files and associated documentation and configuration information; typically, each package is a separate application. By focusing on the package as the managed unit, RPM makes installation and deletion of applications extremely straightforward.

In addition to its package-oriented focus, RPM is designed to support upgrading packages. Once an application has been installed from an RPM package, a newer version of the same application can be installed using RPM. Doing so upgrades the existing application, removing its old files and replacing them with new files. In addition, however, RPM takes care to preserve any customizations that have been made to that application. The Apache Web server application, for example, is commonly installed on Linux machines that need the ability to serve Web pages.

Apache's configuration information, which specifies things such as which files on the system should be made available as Web pages and who should be able to access those Web pages, is stored in a text file, typically /etc/httpd/conf/httpd.conf. Suppose Apache has been installed using RPM and that you have then customized httpd.conf to specify its configuration. If you upgrade Apache using RPM, as part of the upgrade procedure, the RPM application will take precautions to preserve the customizations you have made to the Apache configuration. In contrast, manual upgrades of applications often overwrite any existing configuration files, losing all site customizations the system administrator has made.

Software that manages the applications installed on the system on an application level (such as RPM) does have one potential drawback in comparison with system-wide software management systems (such as PC operating systems like Microsoft Windows or OS/2, which allow the entire system to be upgraded but do not generally allow individual components to be upgraded, added, or removed). Software applications often have interdependencies; some applications work only when other applications are installed.

The Postfix and Sendmail mail transfer agent (MTA) applications that are commonly used on Linux boxes to serve e-mail, for example, can both be configured to require users to authenticate themselves (by submitting a correct user name and password) successfully before they can use the e-mail server. This feature is often used to prevent unauthorized access to the e-mail server, preventing unscrupulous advertisers from using the server as a tool to send unsolicited commercial e-mail (or UCE, popularly known as spam). For this optional feature of Postfix and Sendmail to work, however, additional software must be installed. Both applications use another application, Cyrus SASL, which provides the Simple Authentication and Security Layer (SASL) software that Postfix or Sendmail can use to check user names and passwords. In other words, Postfix and Sendmail depend on Cyrus SASL.

For system-wide software management systems, logical interdependencies between system components such as these are easy to track. All required components are included as part of the system, and upgrading the system upgrades all these components, ensuring that all can still interoperate. On Microsoft Windows 2000, IIS (the application used on Windows to serve Web pages) requires several other applications such as EventLog (the Windows application that records system events, much like the Linux syslogd and klogd software) to be present. Since Windows is managed on a system level, not a package level, this dependency is guaranteed to be satisfied. On Linux systems using RPM, however, the situation is different. On Linux, for example, the Postfix application requires the syslogd application, which records system events. However, RPM provides the flexibility to install some applications but not install others or to uninstall others later. When you install Postfix, you have no guarantee that syslogd is already installed. If syslogd is not installed, Postfix will not work correctly.

To avoid problems, Red Hat developers realized that RPMs must also track dependency information about what software they require for correct functionality, and that the RPM install and uninstall applications must use this dependency information. Because of dependencies, installing Postfix using RPM on a system without syslogd installed generates a warning that syslogd must also be installed. Similarly, attempting to uninstall syslogd from a system that already has Postfix installed generates a warning that installed applications require the software that is being deleted. These warnings can be overridden if necessary, but by default RPM enforces these dependencies (refusing, for example, to let you uninstall syslogd without also uninstalling applications that require it, such as Postfix), preventing you from accidentally breaking applications by inadvertently uninstalling other software that they require to operate.

As part of its implementation, the RPM software maintains a database on the system of all packages that have been installed, and documenting which files those packages have installed on the system. RPM is designed to be queried easily, making it possible for you to search this database to determine what applications have been installed on the system and to see which packages have supplied each file on the system. This feature makes RPM-based systems extremely easy to use, since a single RPM command can be used to view all installed applications on the system.

RPM also maintains a variety of information about each installed file in this system database, such as what permissions each file should have and what size each file should be. Red Hat developers designed this database to be useful for software verification. Over time, installed software will fail to work for reasons as mundane as the system administrator setting incorrect permissions on files or as exotic as nuclear decay of one of the computer's atoms releasing an alpha particle that can affect the computer's memory, corrupting that bit of memory and causing errors. Although RPM cannot prevent all errors that cause installed software to fail (obviously, there's not a single thing any software can do to prevent nuclear decay), it can be used to eliminate common errors. When an application fails, you can use the RPM database to make sure that all files associated with that application still have correct Unix file permissions and that no files associated with that application have become altered or corrupted.

Most of the RPM design goals mentioned so far are intended primarily to ease the life of system administrators and others who regularly install, remove, and upgrade applications or who need to see what is installed or verify that installed applications have been installed correctly. Some of the design goals for RPM are intended primarily not for those sorts of users of RPM but for users who must prepare software to be installed using RPM.

One of the major limitations of early Linux package management utilities was that they could produce packages suitable only for installation on one type of computer: those that used 32-bit Intel-compatible CPUs. By 1994, Linux was beginning to support other CPUs in addition to the originally supported Intel CPUs. (Initially, Digital's Alpha processor and Motorola's 68000 series of processors were among the first additional CPUs that Linux supported. These days, Linux supports dozens of CPU architectures.) This posed a problem for distribution developers such as Red Hat and Debian, and for application vendors who desired to package their software for use on Linux. Because the available packaging methods could not produce packages for multiple architectures, packagers making software for multiple CPUs had to do extra work to prepare their packages.

Furthermore, once the packagers had prepared packages, no method was available to indicate the architecture the packages targeted, making it difficult for end users to know on which machine types they could install the packages.

Red Hat decided to overcome these limitations by incorporating architecture support into RPM, adding features so that the basic setup a packager performs to create a package could be leveraged to produce packages that would run on various CPUs, and so that end users could look at a package and immediately identify for which types of systems it was intended.

The BOGUS distribution's pms packaging system introduced the use of pristine source code to prepare packages. With Red Hat's early RPP package system and other similar early efforts, software packagers would compile software manually, then run commands to produce a package of that compiled software. Any changes made to the application's original source code were not recorded and would have to be recreated by the next person to package that software. Furthermore, end users wanting to know what changes had been made to the software they were running had no method of accessing that information.

With RPM, Red Hat developed a package system that produced two types of packages: binary and source. Binary packages are compiled software that can be installed and used. Source packages contain the source code for that software, along with a file documenting how that source code must be compiled to produce that binary package. This feature is probably the single most significant difference between modern Linux packaging software (such as RPM) and the packaging software used on other systems (such as the pkg format that commercial Unix systems use). Source packaging makes the job of software packager easier, since packagers can use old source packages as a reference when preparing new versions of those packages. Source packages are also convenient for the end user, because they make it easily possible to change options with which that software was compiled and to produce a new binary package that supports the features the user needs.

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.

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.

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?

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.

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 13, Packaging Guidelines covers many issues in creating RPMs, and Chapter 18, Using RPM on Non-Red Hat Linuxes and Chapter 19, RPM on Other Operating Systems 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.

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

Using this table 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.

rpm -Uhv package_file.rpm

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

rpm –e package_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.

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 int 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

To display:

./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.

Almost all installation steps use the rpm command with the –U option, short for upgrade, as introduced in Chapter 2, RPM Overview . The basic syntax is:

rpm -U package_name

For example:

rpm –i jikes-1.16-1.i386.rpm

You can also use the --upgrade long option in place of -U.

Unless something goes wrong, you won’t see any response except for the shell prompt ready for your next command. Options for the rpm command, covered shortly, present positive feedback that the package has been installed.

The rpm command may print out warnings, such as the one following:

warning: pyxf86config-0.3.1-2.i386.rpm: Header V3 DSA
signature: NOKEY, key ID 897da07a

This warning comes from the fact that the package was signed, but the key was not found. Chapter 11, Controlling the Build with rpmbuild covers signing packages. In most cases, warnings such as this one are not that serious. Errors, though, should be treated seriously.

rpm –q jikes

jikes-1.16-1

package jikes is not installed

rpm -Uh jikes-1.16-1.i386.rpm

########################################### [100%]
########################################### [100%]

########################################### [100%]     
warning: user cabbey does not exist - using root
warning: user cabbey does not exist - using root
warning: user cabbey does not exist - using root
########################################### [100%]

rpm -Uhv jikes-1.16-1.i386.rpm

Preparing... ########################################### [100%]
1:jikes ########################################### [100%]

rpm -Uhvv jikes-1.16-1.i386.rpm

D: ============== jikes-1.16-1.i386.rpm
D: Expected size: 702988 = lead(96)+sigs(100)+pad(4)+data(702788)
D: Actual size: 702988
D: jikes-1.16-1.i386.rpm: MD5 digest: OK (2dba32192eca23eb480d1d02a9b6c022)
D: added binary package [0]
D: found 0 source and 1 binary packages
D: opening db environment /var/lib/rpm/Packages joinenv
D: opening db index /var/lib/rpm/Packages rdonly mode=0x0
D: locked db index /var/lib/rpm/Packages
D: ========== +++ jikes-1.16-1
D: opening db index /var/lib/rpm/Depends create mode=0x0
D: Requires: rpmlib(PayloadFilesHavePrefix) <= 4.0-1 YES (rpmlib provides)
D: opening db index /var/lib/rpm/Providename rdonly mode=0x0
D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: ld-linux.so.2 YES (db provides)
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libc.so.6 YES (db provides)
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libm.so.6 YES (db provides)
D: read h# 633 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libstdc++-libc6.2-2.so.3 YES (db provides)
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libc.so.6(GLIBC_2.0) YES (db provides)
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libc.so.6(GLIBC_2.1) YES (db provides)
D: read h# 9 Header V3 DSA signature: NOKEY, key ID 897da07a
D: Requires: libc.so.6(GLIBC_2.1.3) YES (db provides)
D: Requires: rpmlib(CompressedFileNames) <= 3.0.4-1 YES (rpmlib provides)
D: closed db index /var/lib/rpm/Pubkeys
D: closed db index /var/lib/rpm/Depends
D: closed db index /var/lib/rpm/Providename
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages
D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth)D: 0 0 0 0 0 +jikes-1.16-1
D: installing binary packages
D: opening db environment /var/lib/rpm/Packages joinenv
D: opening db index /var/lib/rpm/Packages create mode=0x42
D: getting list of mounted filesystems
D: sanity checking 1 elements
D: opening db index /var/lib/rpm/Name create mode=0x42
D: read h# 707 Header sanity check: OK
D: computing 3 file fingerprints
Preparing... D: computing file dispositions
D: opening db index /var/lib/rpm/Basenames create mode=0x42
########################################### [100%]
package jikes-1.16-1 is already installed
D: closed db index /var/lib/rpm/Basenames
D: closed db index /var/lib/rpm/Name
D: closed db index /var/lib/rpm/Packages
D: closed db environment /var/lib/rpm/Packages

rpm -U --percent jikes-1.16-1.i386.rpm

%% 0.000000
%% 2.661902
%% 5.318614
%% 10.632039
%% 15.945465
%% 18.602177
%% 23.915603
%% 29.229028
%% 34.542453
%% 39.855879
%% 45.169304
%% 50.482729
%% 53.139442
%% 55.796154
%% 61.109580
%% 66.423005
%% 71.736430
%% 74.393143
%% 79.706568
%% 82.363281
%% 87.676706
%% 90.333419
%% 95.646844
%% 98.303557
%% 99.422736
%% 99.910411
%% 99.994892
%% 100.000000

rpm -U --test jikes-1.16-1.i386.rpm

package jikes-1.16-1 is already installed

chap4.txt: not an rpm package (or package manifest):

rpm -q ruby

package ruby is not installed

rpm -U --test eruby-devel-0.9.8-2.i386.rpm

error: Failed dependencies:
eruby-libs = 0.9.8 is needed by eruby-devel-0.9.8-2

rpm -U --test eruby-libs-0.9.8-2.i386.rpm

error: Failed dependencies:
ruby-libs >= 1.6.4 is needed by eruby-libs-0.9.8-2
libruby.so.1.6 is needed by eruby-libs-0.9.8-2

rpm -U package1.rpm package2.rpm .. package100.rpm

rpm -U aspell-en-ca-0.33.7.1-16.i386.rpm aspell-en-gb-0.33.7.1-16.i386.rpm

rpm -U --prefix /new/directory package.rpm

rpm -i --relocate /old/directory=/new/directory package.rpm

rpm -U --root /tmp --dbpath /var/lib/rpm jikes-1.16-1.i386.rpm

error: Failed dependencies:
ld-linux.so.2 is needed by jikes-1.16-1
libc.so.6 is needed by jikes-1.16-1
libm.so.6 is needed by jikes-1.16-1
libstdc++-libc6.2-2.so.3 is needed by jikes-1.16-1
libc.so.6(GLIBC_2.0) is needed by jikes-1.16-1
libc.so.6(GLIBC_2.1) is needed by jikes-1.16-1
libc.so.6(GLIBC_2.1.3) is needed by jikes-1.16-1

rpm -U --excludepath /usr/lib eruby-devel-0.9.8-2.i386.rpm

rpm -U --nodeps eruby-devel-0.9.8-2.i386.rpm

rpm -q eruby-devel

eruby-devel-0.9.8-2

The rpm –U command works for both installation of new packages and for upgrading. When you get beyond simple installations, you begin to see the power of the RPM system where most operations require just one command. The rpm -U command is a very powerful tool and performs some complex operations with just one command. For example, the following commands show the sequence for upgrading the jpilot package, which is used for Palm PDA synchronization.

# rpm -q jpilot

jpilot-0.97-1

# rpm -U jpilot-0.99.2-8.i386.rpm
# rpm -q jpilot

jpilot-0.99.2-8

Note that the old version of the jpilot package is no longer installed. The rpm -U command removed that package.

rpm -U --repackage jpilot-0.99.2-8.i386.rpm

A freshen operation means to install a new version of a package only if you have already installed another version of the package. Thus, a freshen operation is very similar to the upgrade operation except that a freshen requires you to have previously installed the package, while an upgrade can install a package for the first time. The basic syntax for freshening a package is to use the -F option.

rpm -F package_name

You can also use the --freshen long option in place of -F.

As with upgrading, the options to the rpm command are the same, except for the -F or --freshen option that indicates the operation. These are the options discussed in the sections on upgrading and installing software.

The –i or --install option tells the rpm command to run an installation operation, which, as you’d suspect, installs packages. The basic syntax is:

rpm –i filename.rpm

For example:

rpm –i jikes-1.16-1.i386.rpm

The rpm –i command works with the installation options discussed previously. The –U, -F and –i options all accept mostly the same options, except as discussed previously.

All the commands to install packages covered so far assume that you have a local RPM file that you want to install. This is by far the most common case, but you can also use the rpm command to install packages available on a network. With the rpm command, you can get the packages to install by using the FTP or HTTP network protocols.

With the File Transfer Protocol (FTP), the rpm command connects to an FTP file server, downloads the named package, and installs that package. With the HyperText Transfer Protocol (HTTP) used for Web pages, the rpm command connects to a Web server, downloads the named package, and installs that package.

rpm -i ftp://hostname/path/to/file/filename.rpm

rpm -i ftp://www-126.ibm.com/pub/jikes/jikes-1.16-1.src.rpm

rpm -i ftp://unclejoe@www-126.ibm.com/pub/jikes/jikes-1.16-1.src.rpm

rpm -i ftp://unclejoe:workers@www-126.ibm.com/pub/jikes/jikes-1.16-1.src.rpm

rpm –i http://ftp.redhat.com/pub/contrib/noarch/SRPMS/Squeak-sources-3-1.src.rpm

Source RPMs contain the source code used to build an application or programming library and the scripts used to build the software into the application or library. These scripts are called the recipes for building the software.

Source RPMs usually contain program source code. They may also contain patches to program sources, scripts to build the program, special files used by desktop environments, icons, and other files considered to be part of the source code, such as programming guides.

In most cases, each binary RPM will have a corresponding source RPM. This is not always true, however.

One source RPM may contain enough shared program code to build multiple application RPMs. Furthermore, the source code is not available for all packages. Commercial applications, for example, rarely come with source code. In this case, obviously, no source RPMs are available. Or, a source RPM for a commercial application may provide no source code, but still provide a way to build the resulting application. See Chapter 9, Working with Spec Files for more on the source files and options for not including the sources in a source RPM.

As before, you can use the rpm –q command to query whether a package is installed. After running the rpm –e command, you can run the rpm –q command to check whether the package has been removed. If the rpm –q command shows that the package is not installed, that tells you the erase operation has worked.

For example:

# rpm -q jikes

jikes-1.16-1

# rpm -e jikes-1.16-1
# rpm -q jikes

package jikes is not installed

You can remove multiple packages at once by listing each package consecutively on the command line. For example:

rpm -e aspell-en-ca-0.33.7.1-16 aspell-en-gb-0.33.7.1-16

This command removes the aspell-en-ca-0.33.7.1-16 and aspell-en-gb-0.33.7.1-16 packages.

The --allmatches option tells the rpm command to remove all packages with names that match the names you pass on the command line. If you do not use the --allmatches option, the rpm command will issue an error if more than one package matches the name or names you pass on the command line.

The --nodeps option tells the rpm command to skip the test of dependencies. Use this option when you really, really, want to uninstall a package.

The --repackage option, described previously, tells the rpm command to create a package, an RPM file, from any packages it would erase. These packages will appear in the default repackage directory, which is normally /var/spool/repackage/. Check your RPM settings to be sure of the directory configured on your system.

Similar to the options when installing or upgrading packages, you can use the --noscripts and --notriggers options when removing packages. The --noscripts option tells the rpm command not to run any uninstallation scripts. You can refine this by using either --nopreun or --nopostun in place of the --noscripts option.

The --nopreun option tells the rpm command not to run the pre-uninstallation scripts. The --nopostun option tells the rpm command not to run the post-uninstallation scripts.

The --notriggers option works in a similar fashion. The --notriggers option tells the rpm command not to execute any triggers. For a finer grain of control, use --notriggerun to prevent any uninstallation triggers and --notriggerpostun to prevent any post-uninstallation triggers.

The basic format of the rpm –q command follows:

rpm –q package_name

You need to provide the name of a package to query. For example:

rpm -q telnet-0.17

This command returns the name of the package, if installed. For example:

telnet-0.17-20

If the package is not installed, you’ll see a message like the following:

package telnet-0.17 is not installed

You can provide the whole package name to the rpm command, which includes the name, the version, and the RPM package number, as discussed in Chapter 2, RPM Overview . You can also just provide the name and version number, as shown previously, or just the base name of the package.

For example, the following command uses just the base name of the package:

$ rpm -q telnet

telnet-0.17-20

Note

The rpm –q command expects a package name. Although it supports some amount of customized queries, you really need to know which packages you want the rpm command to report on.

You can provide more than one package name; the rpm command reports on each package, as shown following.

$ rpm -q telnet telnet-server

telnet-0.17-20

telnet-server-0.17-20

You need to change the way you query if you want to perform searches when you do not know the full package name in advance. The following sections cover options for creating various queries.

Up to now, we have used the rpm command to query only for specific packages. The –a option tells the rpm command to query for all packages. You can also use the longer option, --all, in place of –a.

For example:

rpm -qa

This command returns every package installed on your system, quite a few packages. The packages are returned one per line, as shown following.

words-2-17

kudzu-0.99.23-1

openldap-2.0.11-13

rpm-4.0.3-1.03

kernel-smp-2.4.7-10

quota-3.01pre9-3

expat-1.95.1-7

groff-perl-1.17.2-3

perl-DateManip-5.39-5

perl-libnet-1.0703-6

perl-URI-1.12-5

perl-XML-Parser-2.30-7

perl-XML-Twig-2.02-2

a2ps-4.13b-15

4Suite-0.11-2

XFree86-xfs-4.1.0-3

ghostscript-6.51-12

tcl-8.3.3-65

portmap-4.0-38

bind-utils-9.1.3-4

ftp-0.17-12

micq-0.4.6.p1-2

Note

This output has been modified to meet size constraints. Try the rpm –qa command to see the full output for your system.

There may be over a thousand packages on your system. Even so, the rpm –qa command executes surprisingly fast.

When you query all the installed packages, you get too much output for most purposes, other than to get a general idea of the magnitude of packages installed on your system. But if you cannot remember a package name, there's no real option, other than writing your own RPM query program.

You can take advantage of the power of the Linux shells, though, and the wonderful ability to pipe the output of one command into another to work around this problem. With the large amount of output, you may want to pipe the output to the more or less programs, and display the output one page at a time.

Cross Reference

For more information on the more or less commands, view the online manuals with the man more and man less commands.

Even with more and less, the rpm –qa command outputs too much information to be really useful, unless you can somehow filter the information automatically.

One of the common problems with package management comes when you want to track a given file on your system back to the package that “owns” the file (that is, the package that, when installed, installed the particular file).

The -qf option tells the rpm command to query for all packages that own a particular file. You can also use the longer option, --file, in place of –f. The basic syntax follows:

rpm -qf filename

For example, the grep command used in previous examples is really a file. (Just about all Linux commands are a file of some sort, be it a shell script or an executable application.) You can use a few Linux commands to determine which package provides this handy program.

First, we need the exact path to the file. For Linux commands, you can use the which command, if the program is in your path. (The grep program must be in your path, or commands with grep will fail.)

Try the following command:

which grep

This command returns the path to grep:

/bin/grep

We can now check which package owns this file with the following command:

# rpm -qf /bin/grep

grep-2.4.2-7

You can also use the Linux back-tick operator to perform this check with one command.

# rpm -qf `which grep`

grep-2.4.2-7

Production: note use of back-quote, `, above. Don’t change to “smart quotes” please. -Eric

If you use the bash shell, you can use the $(command parameters) syntax in place of the back tick, or `, characters. For example:

# rpm -qf $(which grep)

grep-2.4.2-7

If no package owns a given file, you’ll see output like the following:

# rpm -qf mail

file mail is not owned by any package

Often, the package that owns a file does not have an intuitive name. The ssh command, for example, is owned by the openssh-clients package, as shown following:

# rpm -qf `which ssh`

openssh-clients-3.1p1-2

As you can see, the name of a command does not always correspond directly to the name of the package that provides that command. This is where the rpm –qf command proves very useful. Otherwise, you would just have to know that OpenSSH is the project responsible for this command.

Symbolic Links

The rpm -qf command follows symbolic links. This was not always true with older versions of the rpm command, but the modern rpm command can now trace package ownership to files placed in linked directories.

For example, the directory /usr/lib/X11 is a link to the real directory, /usr/X11R6/lib/X11. You can track the package ownership of a file in that directory, XKeysymDB, for example, by using the following command:

# rpm -qf /usr/lib/X11/XKeysymDB

XFree86-4.2.0-72

This file, XKeysymDB, really resides in /usr/X11R6/lib/X11.

The –i option with an rpm query command tells the rpm command to output descriptive information about the package. You can also use the longer option, --info, in place of –i. The basic syntax is:

rpm -qi package

Warning

The order of the command-line options is very important. Remember that the rpm command has the following general syntax:

rpm –MajorOperation –extra_options packages_or_files

The rpm –i command installs packages. The rpm –q command queries packages. The rpm –qi command outputs the descriptive information on packages. If you make a mistake and place the i in front of the q, you are telling the rpm command to perform a different operation.

When you run this command, being very careful with the order of the options, you’ll see output like the following, which describes the tcsh shell package.

# rpm -qi tcsh-6.10-6

Name : tcsh Relocations: (not relocateable)

Version : 6.10 Vendor: Red Hat Inc.

Release : 6 Build Date: Sun 24 Jun 2001 10:45:29

PM CDT

Install date: Fri 14 Dec 2001 10:45:39 AM CST Build

Host: porky.devel.redhat.com

Group : System Environment/Shells Source RPM: tcsh-6.10-6.src.rpm

Size : 764000 License: distributable

Packager : Red Hat Inc. <http://bugzilla.redhat.com/bugzilla>

URL : http://www.primate.wisc.edu/software/csh-tcsh-book/

Summary : An enhanced version of csh, the C shell.

Description :

Tcsh is an enhanced but completely compatible version of csh, the C

shell. Tcsh is a command language interpreter which can be used both

as an interactive login shell and as a shell script command processor.

Tcsh includes a command line editor, programmable word completion,

spelling correction, a history mechanism, job control and a C language

like syntax.

From this description, you can find out a lot about a package, such as where it comes from. Note how the description also names the source RPM used to build the package programs.

Cross Reference

The sections on custom queries following in this chapter show how you can query for any information stored in a package header, including all of the information shown with the rpm –qi command, as well as any other header tag.

RPM packages can be placed into groups, merely arbitrary names for a set of packages. The rpm –qi command, shown previously, lists the group for a package, if there is one. For the tcsh package shown in the previous example, the package is System Environment/Shells.

The –g option to the rpm –q command tells the rpm command to list all the packages in a given group. You can also use the longer option, --group, in place of –g. The basic syntax follows:

rpm –qg group_name

For example:

# rpm -qg "System Environment/Shells"

bash-2.05b-5

sh-utils-2.0.12-3

ash-0.3.8-5

tcsh-6.12-2

Note

This group has a space in its name, so you need quotation marks to pass the group name as one parameter to the rpm command.

The –l (ell) option queries all the files in a package. You can also use the longer option, --list, in place of –l. The basic syntax is:

rpm –ql package

For example, to query the files in the tcsh package, you’ll see the following:

# rpm -ql tcsh

/bin/csh

/bin/tcsh

/usr/share/doc/tcsh-6.10

/usr/share/doc/tcsh-6.10/FAQ

/usr/share/doc/tcsh-6.10/Fixes

/usr/share/doc/tcsh-6.10/NewThings

/usr/share/doc/tcsh-6.10/complete.tcsh

/usr/share/doc/tcsh-6.10/eight-bit.txt

/usr/share/doc/tcsh-6.10/tcsh.html

/usr/share/doc/tcsh-6.10/tcsh.html/header.html

/usr/share/doc/tcsh-6.10/tcsh.html/index.html

/usr/share/doc/tcsh-6.10/tcsh.html/lists.html

/usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man

/usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man2html

/usr/share/doc/tcsh-6.10/tcsh.html/top.html

/usr/share/locale/de/LC_MESSAGES/tcsh

/usr/share/locale/el/LC_MESSAGES/tcsh

/usr/share/locale/es/LC_MESSAGES/tcsh

/usr/share/locale/fr/LC_MESSAGES/tcsh

/usr/share/locale/it/LC_MESSAGES/tcsh

/usr/share/locale/ja/LC_MESSAGES/tcsh

/usr/share/man/man1/tcsh.1.gz

Note

You can pass more than one package name to this option, but it won’t tell you which package owns which file. Use the --filesbypkg option to list files by package (see the related sidebar).

Listing Files By Package

The --filesbypkg option outputs the files by package, so you can make some sense of a list of files from more than one package.

For example:

# rpm -q --filesbypkg file openssh-clients

file /usr/bin/file

file /usr/share/magic

file /usr/share/magic.mgc

file /usr/share/magic.mime

file /usr/share/man/man1/file.1.gz

file /usr/share/man/man5/magic.5.gz

openssh-clients /etc/ssh/ssh_config

openssh-clients /usr/bin/sftp

openssh-clients /usr/bin/slogin

openssh-clients /usr/bin/ssh

openssh-clients /usr/bin/ssh-add

openssh-clients /usr/bin/ssh-agent

openssh-clients /usr/bin/ssh-keyscan

openssh-clients /usr/share/man/man1/sftp.1.gz

openssh-clients /usr/share/man/man1/slogin.1.gz

openssh-clients /usr/share/man/man1/ssh-add.1.gz

openssh-clients /usr/share/man/man1/ssh-agent.1.gz

openssh-clients /usr/share/man/man1/ssh-keyscan.1.gz

openssh-clients /usr/share/man/man1/ssh.1.gz

Use this option without –l, because the –l option will also list the files alone, without any package name.

The –v (verbose) option can give you more information on the files when used with the various query options. For example:

# rpm -qlv tcsh

lrwxrwxrwx 1 root root 4 Jun 24 2001 /bin/csh -> tcsh

-rwxr-xr-x 1 root root 288604 Jun 24 2001 /bin/tcsh

drwxr-xr-x 2 root root 0 Jun 24 2001 /usr/share/doc/tcsh-6.10

-rw-r--r-- 1 root root 8306 Aug 25 2000 /usr/share/doc/tcsh-6.10/FAQ

-rw-r--r-- 1 root root 64761 Nov 19 2000 /usr/share/doc/tcsh-6.10/Fixes

-rw-r--r-- 1 root root 6518 Oct 2 1998 /usr/share/doc/tcsh-6.10/NewThings

-rw-r--r-- 1 root root 41328 Nov 19 2000 /usr/share/doc/tcsh-6.10/complete.tcsh

-rw-r--r-- 1 root root 4668 Jun 24 2001 /usr/share/doc/tcsh-6.10/eight-bit.txt

drwxr-xr-x 2 root root 0 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html

-rw-r--r-- 1 root root 124 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/header.html

lrwxrwxrwx 1 root root 8 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/index.html -> top.html

-rw-r--r-- 1 root root 911 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/lists.html

-rw-r--r-- 1 root root 0 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man

-rw-r--r-- 1 root root 22542 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man2html

-rw-r--r-- 1 root root 693 Jun 24 2001 /usr/share/doc/tcsh-6.10/tcsh.html/top.html

-rw-r--r-- 1 root root 45861 Jun 24 2001 /usr/share/locale/de/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 47566 Jun 24 2001 /usr/share/locale/el/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 47413 Jun 24 2001 /usr/share/locale/es/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 47156 Jun 24 2001 /usr/share/locale/fr/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 48264 Jun 24 2001 /usr/share/locale/it/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 18682 Jun 24 2001 /usr/share/locale/ja/LC_MESSAGES/tcsh

-rw-r--r-- 1 root root 62399 Jun 24 2001 /usr/share/man/man1/tcsh.1.gz

This information is the same as a long listing on the files.

As you can see, the –l option results in quite a lot of output. In some cases, though, you aren’t interested in documentation and other miscellaneous files in the package. It’s the commands and libraries that cause the most package-related problems. To help with this, you can use a series of rpm options to list only certain types of files.

The –c option tells the rpm –q command to list the configuration files for a package. You can also use the longer option, --configfiles, in place of –c. The basic syntax is:

rpm –qc package_name

For example:

# rpm -qc bash

/etc/skel/.bash_logout

/etc/skel/.bash_profile

/etc/skel/.bashrc

This command lists the configuration files for the bash package.

Some packages don’t have configuration files, as shown following:

# rpm -qc python

#

In this case, the rpm command provides no output. Other packages have a lot of configuration files, such as the sendmail mail transfer agent, as shown following:

# rpm -qc sendmail

/etc/aliases

/etc/mail/Makefile

/etc/mail/access

/etc/mail/domaintable

/etc/mail/helpfile

/etc/mail/local-host-names

/etc/mail/mailertable

/etc/mail/sendmail.mc

/etc/mail/statistics

/etc/mail/trusted-users

/etc/mail/virtusertable

/etc/rc.d/init.d/sendmail

/etc/sendmail.cf

/etc/sysconfig/sendmail

/usr/lib/sasl/Sendmail.conf

As with the –l option, the –v option provides more information on each file, as shown following:

#rpm -qcv bash

-rw-r--r-- 1 root root 24 Jul 9 2001 /etc/skel/.bash_logout

-rw-r--r-- 1 root root 191 Jul 9 2001 /etc/skel/.bash_profile

-rw-r--r-- 1 root root 124 Jul 9 2001 /etc/skel/.bashrc

Similarly to the –c option, the –d option tells the rpm –q command to list just the documentation files for a package. The basic syntax is:

rpm –qd package_name

For example:

# rpm -qd tcsh

/usr/share/doc/tcsh-6.10/FAQ

/usr/share/doc/tcsh-6.10/Fixes

/usr/share/doc/tcsh-6.10/NewThings

/usr/share/doc/tcsh-6.10/complete.tcsh

/usr/share/doc/tcsh-6.10/eight-bit.txt

/usr/share/doc/tcsh-6.10/tcsh.html/header.html

/usr/share/doc/tcsh-6.10/tcsh.html/index.html

/usr/share/doc/tcsh-6.10/tcsh.html/lists.html

/usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man

/usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man2html

/usr/share/doc/tcsh-6.10/tcsh.html/top.html

/usr/share/man/man1/tcsh.1.gz

Note

You can add the –v option to all of the file-listing options to get more information.

You can also use the longer option, --docfiles, in place of –d.

The –s option to the rpm –q command lists the state of each file in a package. The basic syntax follows.

rpm –qs package_name

For example:

# rpm -qs tcsh

normal /bin/csh

normal /bin/tcsh

normal /usr/share/doc/tcsh-6.10

normal /usr/share/doc/tcsh-6.10/FAQ

normal /usr/share/doc/tcsh-6.10/Fixes

normal /usr/share/doc/tcsh-6.10/NewThings

normal /usr/share/doc/tcsh-6.10/complete.tcsh

normal /usr/share/doc/tcsh-6.10/eight-bit.txt

normal /usr/share/doc/tcsh-6.10/tcsh.html

normal /usr/share/doc/tcsh-6.10/tcsh.html/header.html

normal /usr/share/doc/tcsh-6.10/tcsh.html/index.html

normal /usr/share/doc/tcsh-6.10/tcsh.html/lists.html

normal /usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man

normal /usr/share/doc/tcsh-6.10/tcsh.html/tcsh.man2html

normal /usr/share/doc/tcsh-6.10/tcsh.html/top.html

not installed /usr/share/locale/de/LC_MESSAGES/tcsh

not installed /usr/share/locale/el/LC_MESSAGES/tcsh

not installed /usr/share/locale/es/LC_MESSAGES/tcsh

not installed /usr/share/locale/fr/LC_MESSAGES/tcsh

not installed /usr/share/locale/it/LC_MESSAGES/tcsh

not installed /usr/share/locale/ja/LC_MESSAGES/tcsh

normal /usr/share/man/man1/tcsh.1.gz

You can also use the longer option, --state, in place of –s.

You can combine the –s option with other file filters, such as –d, for listing only the documentation files for a package.

Table 5-2 lists the states that the rpm command supports.

Table 5-2 RPM File States

Sometimes files in a package may have been skipped during installation with options such as --excludedocs. This can lead to non-normal states. You may have also modified files installed from a given package.

Cross Reference

See Chapter 3, Using RPM for more on installing RPMs.

RPM packages can have preinstallation, postinstallation, preuninstallation, and postuninstallation scripts. These are scripts that the rpm command will execute before and after installing a package, as well as before and after removing the package. The --scripts option to the rpm –q command lists the scripts associated with a package. The basic syntax follows:

rpm -q --scripts package_name

For example:

# rpm -q --scripts tcsh

postinstall scriptlet (through /bin/sh):

if [ ! -f /etc/shells ]; then

echo "/bin/tcsh" >> /etc/shells

echo "/bin/csh" >> /etc/shells

else

grep '^/bin/tcsh$' /etc/shells > /dev/null || echo "/bin/tcsh" >> /etc/shell

s

grep '^/bin/csh$' /etc/shells > /dev/null || echo "/bin/csh" >> /etc/shells

fi

postuninstall scriptlet (through /bin/sh):

if [ ! -x /bin/tcsh ]; then

grep -v '^/bin/tcsh$' /etc/shells | grep -v '^/bin/csh$'> /etc/shells.rpm

mv /etc/shells.rpm /etc/shells

fi

PRODUCTION: NOTE THE “fi” on a line by itself at the end of this listing. Thanks, -Eric

The simple scripts shown here add an entry to the /etc/shells file and clean up the entry when uninstalled.

Cross Reference

Cleaning up any changes your package makes on uninstallation is a very good idea. See the chapters in Part II, Creating RPMs, for details on making your own well-behaved packages.

Other packages have more complex scripts, as shown following:

# rpm -q --scripts sendmail

preinstall scriptlet (through /bin/sh):

/usr/sbin/useradd -u 47 -d /var/spool/mqueue -r -s /dev/null mailnull >/dev/null

2>&1 || :

postinstall scriptlet (through /bin/sh):

#

# Convert old format to new

#

if [ -f /etc/mail/deny ] ; then

cat /etc/mail/deny | \

awk 'BEGIN{ print "# Entries from obsoleted /etc/mail/deny"} \

{print $1" REJECT"}' >> /etc/mail/access

cp /etc/mail/deny /etc/mail/deny.rpmorig

fi

for oldfile in relay_allow ip_allow name_allow ; do

if [ -f /etc/mail/$oldfile ] ; then

cat /etc/mail/$oldfile | \

awk "BEGIN { print \"# Entries from obsoleted /etc/mail/$oldfile

\" ;} \

{ print \$1\" RELAY\" }" >> /etc/mail/access

cp /etc/mail/$oldfile /etc/mail/$oldfile.rpmorig

fi

done

#

# Oops, these files moved

#

if [ -f /etc/sendmail.cw ] ; then

cat /etc/sendmail.cw | \

awk 'BEGIN { print "# Entries from obsoleted /etc/sendmail.cw" ;} \

{ print $1 }' >> /etc/mail/local-host-names

cp /etc/sendmail.cw /etc/sendmail.cw.rpmorig

fi

#

# Rebuild maps (next reboot will rebuild also)

#

{ /usr/bin/newaliases

for map in virtusertable access domaintable mailertable

do

if [ -f /etc/mail/${map} ] ; then

/usr/bin/makemap hash /etc/mail/${map} < /etc/mail/${map}

sleep 1

fi

done

} > /dev/null 2>&1

/sbin/chkconfig --add sendmail

preuninstall scriptlet (through /bin/sh):

if [ $1 = 0 ]; then

/etc/rc.d/init.d/sendmail stop >/dev/null 2>&1

/sbin/chkconfig --del sendmail

fi

postuninstall scriptlet (through /bin/sh):

if [ "$1" -ge "1" ]; then

/etc/rc.d/init.d/sendmail condrestart >/dev/null 2>&1

fi

exit 0

In this case, the main script is the post-install script, which tries to convert old-format data into the new format, thereby helping users upgrade to the newer release.

The --changelog option lists what has changed, as described in a file that logs changes, from previous versions of a given package. The change log is just a convention, so not all packages will sport this nifty feature. In addition, the change log for many packages documents the changes in the RPM packaging, not the changes in the underlying application. If a change log is available, however, this can prove a very good way to help determine whether you want to upgrade to a new version of a package.

For example, a network server application may have been updated to fix some security problems. In that case, you likely want to upgrade. Other changes may not affect your site, leading you to decide not to upgrade.

The basic format of the command is:

rpm –q --changelog package_name

For example, the following shows the beginning of the log-change log for the bash package, with names and e-mail addresses changed to protect the innocent:

# rpm -q --changelog bash

* Fri Aug 23 2002 Bob Marley <bob@marley.com.>

- re-bzip the docs, something was corrupted

* Thu Aug 22 2002 Peter Tosh <peter@tosh.com> 2.05b-4

- Fix history substitution modifiers in UTF-8 (bug #70294, bug #71186).

- Fix ADVANCE_CHAR at end of string (bug #70819).

- docs: CWRU/POSIX.NOTES no longer exists, but ship POSIX.

* Wed Aug 07 2002 Jimmy Cliff <jimmy@cliff.com> 2.05b-3

- Fixed out of memory problem with readline.

* Tue Jul 23 2002 Jimmy Cliff <jimmy@cliff.com> 2.05b-2

- Added symlink for sh.1 in man1 section so that man sh works (#44039).

The rpm command is very flexible in allowing you to combine queries. Just start the command with rpm –q and add the various options either on their own, such as –q with –s and –f, or together, such as –qsf.

The following sections show a few handy combinations of the options you can use for real-world package-management tasks.

The --qf or --queryformat option allows you to create custom queries with the rpm command, although in a rather difficult manner. You need to pass a query format string, the syntax of which originates with the C printf function and requires precision.

The basic syntax of the query format is %{tag_name}. (The percent sign is about the only part that comes from the C printf function.) You can combine tag names to display more than one item per package. You can also add formatting options following C language conventions.

For example, to list all package names, use a command like the following:

# rpm -qa --qf "%{NAME}"

redhat-menusglibccracklibgdbmgmplibacllibjpeglincpcreshadow-

utilslibtermcapfreetypeinfofileutilspsmiscntpmountcracklib-dictskrb5-libscyrus-

saslusermodeXftlibpnglibxmllibbonobopythonpygtk2pyxf86configredhat-config-

usersredhat-config-keyboardrpm404-pythongnome-vfs2libgnomeuiashbind-utilscyrus-

sasl-plaindos2unixethtoolfingergroffautofskbdconfiglesslibtool-

libslockdevmailcapMAKEDEVmouseconfignetpbmntsysvORBitpartedppppsutilsrdaterhnlibrp

mrshsetuptoolstatserialtarlilopciutilstimeconfigunzipkernel-pcmcia-

csanacronXFree86

This command used the simplest format, which is just the value of the tag in the package headers, in this case the package names. Because we used no other formatting, this command outputs all the package names smashed together. To deal with this problem in the output, you can place a \n, the C language convention for a newline character, at the end of the format string. This fixes the output considerably.

For example (showing just the first few entries):

# rpm -qa --qf "%{NAME}\n"

redhat-menus

glibc

cracklib

gdbm

gmp

libacl

libjpeg

linc

pcre

shadow-utils

libtermcap

freetype

info

fileutils

psmisc

ntp

mount

cracklib-dicts

krb5-libs

cyrus-sasl

usermode

Xft

This command provides a custom query that is essentially the same as the rpm -qa command. You’ll likely not use this command in favor of the simpler rpm option, but you can use this example as a guide for creating your own custom queries.

Cross Reference

A great many of the command-line options to the rpm command are defined as popt aliases. These popt aliases define the rpm command-line options in terms of longer query format strings. See Chapter 20, Customizing RPM Behavior for more information on popt.

You can add items to the query string and use C language conventions for formatting and controlling the amount of space provided for each item output.

For example, the following command prints the name and platform for all packages, showing the first few entries, formatted with 20 characters for each item:

rpm -qa --qf "%-20{NAME} %-20{PLATFORM}\n"

redhat-menus noarch-redhat-linux-gnu

glibc i686-redhat-linux-gnu

cracklib i386-redhat-linux

gdbm i386-redhat-linux-gnu

gmp i386-redhat-linux-gnu

libacl i386-redhat-linux-gnu

libjpeg i386-redhat-linux

linc i386-redhat-linux-gnu

pcre i386-redhat-linux

shadow-utils i386-redhat-linux-gnu

libtermcap i386-redhat-linux

freetype i386-redhat-linux-gnu

info i386-redhat-linux-gnu

fileutils i386-redhat-linux-gnu

psmisc i386-redhat-linux

ntp i386-redhat-linux-gnu

mount i386-redhat-linux-gnu

cracklib-dicts i386-redhat-linux

krb5-libs i386-redhat-linux-gnu

cyrus-sasl i386-redhat-linux-gnu

usermode i386-redhat-linux-gnu

Xft i386-redhat-linux-gnu

If what you’ve seen so far isn’t enough, the rpm command supports a number of extra queries, mostly of use to developers at Red Hat.

Table 5-7 summarizes these extra queries.

Table 5-7 Extra Queries

To verify your entire system, use the -a option.

For example:

# rpm -Va

SM5....T c /usr/share/info/dir

.......T c /etc/krb5.conf

.......T /usr/share/pixmaps/gnome-default-dlg.png

.......T /usr/share/pixmaps/gnome-error.png

.......T /usr/share/pixmaps/gnome-info.png

.......T /usr/share/pixmaps/gnome-question.png

.......T /usr/share/pixmaps/gnome-warning.png

S.5....T c /etc/sysconfig/pcmcia

.....U.. /dev/winradio0

Each line that the rpm command outputs indicates a problem with the given file. The rpm command uses letter codes to show the type of the problem. Table 5-8 lists the letter codes with their meanings.

Table 5-8 RPM verify output codes

You can use a number of options to tell the verification command specifically what to check for or not check for. Table 5-9 lists these options.

Table 5-9 Controlling the verification

Cross Reference

Chapter 11, Controlling the Build with rpmbuild covers another option for verifying a package file, the rpm –K command.

The --nofiles option is often used with the –Va option to verify the whole system but skip tests of file attributes. This command is used to often it has become an idiom for RPM usage, especially for debugging RPM problems. Run a command like the following:

$ rpm -Va --nofiles

As mentioned before, the RPM database resides in the /var/lib/rpm. You can back up the RPM database by using commands such as the following:

# cd /var/lib

# tar cvf rpmdb.tar ./rpm

# gzip rpmdb.tar

These commands create a tar archive from the contents of the rpm directory (where the RPM database is stored) and compress the file with the gzip command.

Note

Adding the z option to the tar command can create a compressed archive directly, without the need for the gzip command.

If the RPM database has been corrupted in some way, you can use the --rebuilddb option to tell the rpm command to rebuild your database.

For example:

rpm --rebuilddb

This command rebuilds the RPM database from the installed packages, the file named Packages in the /var/lib/rpm directory. Only the Packages file is required. All the other files can be recreated from the Packages file. If your database is OK, this command won't do much, other than shrink the size of your RPM database by removing unused entries. This command will take some time to execute, though.

Warning

Before running this command, back up your RPM database.

To check that the rpm --rebuilddb command has not damaged the RPM database, you can check with a file listing, query all packages, and then check the results of the rpm –rebuilddb command with another file listing when done.

Another useful technique that can help with a corrupted RPM database is to use the db_dump and db_load utilities that come with RPM (from the SleepyCat DB database library). Use db_dump to dump the Packages file. Then, use db_load to reload the Packages file. The act of dumping and restoring may fix a corrupted file. As always, back up your RPM database prior to performing these commands.

If all else fails, use the --initdb option to tell the rpm command to create a new empty RPM database. In almost all cases, you do not want to create a new RPM database, since this database will be empty. It will not have any knowledge about the packages you have already installed on your system. That could lead to a lot of problems, since you have the files installed, but the RPM system just doesn’t know about them.

The basic syntax follows.

rpm --initdb

Note

This command should not damage an existing database.

If the RPM system cannot be rebuilt, you may have to reinstall the operating system to recreate a clean system. In general, if things are this far gone, reinstalling may be your best answer instead of wiping the RPM database and creating an empty database.

You can also use the --dbpath option to tell the rpm command to create an RPM database in a different directory.

For example:

mkdir /tmp/rpm

rpm --initdb --dbpath /tmp/rpm

These commands create a temporary directory and an RPM database in the /tmp/rpm directory.

After running this command, you can examine the files created.

# ls -l /tmp/rpm

total 288

-rw-r--r-- 1 root root 8192 Oct 10 20:29 __db.001

-rw-r--r-- 1 root root 1310720 Oct 10 20:29 __db.002

-rw-r--r-- 1 root root 360448 Oct 10 20:29 __db.003

-rw-r--r-- 1 root root 12288 Oct 10 20:29 Packages

This shows an empty RPM database.

In RPM terminology, each package provides capabilities. A capability is simply a text string that the package claims it provides. In most cases, a capability names a file or a package. But the capability can be any arbitrary text string.

Other packages can then depend on certain capabilities. (You can use this concept in building your own packages.) Each package lists the capabilities it requires as well as the capabilities it provides.

Cross Reference

Package dependencies and capabilities are very important when creating spec files for building your own RPM packages, the subject of Chapter 9, Working with Spec Files .

When you install a package, the capability information is stored in the RPM database. When you remove a package, the rpm command checks the RPM database. If the package you are trying to remove provides a capability that another package needs, the command will generate an error. If you try to remove a package that other packages depend on, you'll see an error like the following:

# rpm -e setup

error: Failed dependencies:

setup is needed by (installed) basesystem-8.0-1

setup >= 2.0.3 is needed by (installed) initscripts-6.95-1

setup >= 2.5.4-1 is needed by (installed) filesystem-2.1.6-5

setup is needed by (installed) xinetd-2.3.7-2

setup is needed by (installed) dump-0.4b28-4

To verify that the package has not been removed, you can query for the package after trying to remove it, as shown following:

# rpm -q setup

setup-2.5.20-1

This shows that the rpm command has not removed the setup package due to the errors.

Cross Reference

Chapter 3, Using RPM covers ways to force the rpm command to do what you want, although this can cause problems if you try to force the issue and remove a crucial package. In virtually all cases, do not use any of the force options, as this can cause problems with the RPM system, since the force options are purposely ignoring safety checks performed by the rpm command.

Many capabilities that packages require are system libraries, especially shared libraries. Shared libraries, which usually have a .so file extension (short for shared object), provide a memory-efficient means for applications to share program code. These libraries may also have a .so.number extension, such as libc.so.6.

Note

Shared libraries on Windows are called DLLs, short for Dynamic Link Libraries. The implementations differ, but the Windows DLL concept is similar to Linux and Unix shared objects.

Shared libraries have been part of Linux for a long time and have nothing to do with the RPM system. Shared libraries accessed by a program, however, represent natural dependencies. Because so many programs depend on shared libraries, the RPM system can automatically handle many shared-library dependencies.

Note

To list the shared libraries that a program accesses, use the ldd command, for example:

$ ldd /bin/grep

libc.so.6 => /lib/i686/libc.so.6 (0x42000000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Other dependencies include version-specific dependencies.

An application may depend on a capability provided by another package. It may also depend on the capability that a specific version of another package provides. For example, some add-ons to the Apache Web server depend on the version of Apache. The Apache 2.0 version made a number of changes that affect add-on packages. Some Apache add-on packages depend on version 1.3; others depend on version 2.0.

Most package dependencies assume some level of compatibility and require a version at or above a given version number (for example, version 2.0 or later).

Note

You’ll see more version dependencies when applications make major changes, such as the change from 1.3 to 2.0 for the Apache Web server.

Some packages may provide capabilities that interfere with those in other packages. This is called a conflict. Installing conflicting packages is an error. For example, the httpd package (the Apache Web server) conflicts with the thttpd package. Both packages want to provide the primary Web server for a system.

The RPM system will prevent you from installing packages that conflict with other packages. You can force the issue, using the techniques described in Chapter 3, Using RPM , and override the RPM system. But in most cases, you should not install packages that conflict.

The RPM system supports one more type of dependency, called obsoletes. This refers to a capability that a package provides that makes another capability obsolete. For example, a new version of the perl interpreter may make an older version obsolete. In most cases, the obsoletes dependency should be used when the name of a package changes. For example, the apache Web server package became the httpd package. You would expect the new package, httpd, to obsolete the old package name, apache.

This brings the total to four types of dependencies that the RPM system tracks:

*Requires, which tracks the capabilities a package requires

*Provides, which tracks the capabilities a package provides for other packages

*Conflicts, which describes the capabilities that if installed, conflict with capabilities in a package

*Obsoletes, which describes the capabilities that this package will make obsolete

Packages advertise this dependency information. Each dependency holds the type, such as requires, a capability, such as a shared library or a package name, and optionally a version number, such as requiring the python package at a version number greater than or equal to 2.2 (python >= 2.2).

You can check package dependencies by using, as you’d guess, the rpm command.

The first and most important step is to determine what capabilities a package requires. If all the required capabilities are met, you can safely install the package (barring other things that can go wrong, such as conflicts). The requires dependencies are by far the most important.

The --requires option to the rpm –q command lists the capabilities a given package requires. The basic syntax is:

rpm –q query_options --requires packages

For example:

$ rpm -qp --requires sendmail-8.12.5-7.i386.rpm

/usr/sbin/alternatives

rpmlib(VersionedDependencies) <= 3.0.3-1

chkconfig >= 1.3

/usr/sbin/useradd

/bin/mktemp

fileutils

gawk

sed

sh-utils

procmail

bash >= 2.0

/bin/sh

/bin/sh

/bin/sh

/bin/sh

/bin/sh

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

/bin/bash

libcrypto.so.2

libcrypt.so.1

libc.so.6

libc.so.6(GLIBC_2.0)

libc.so.6(GLIBC_2.1)

libc.so.6(GLIBC_2.1.3)

libc.so.6(GLIBC_2.2)

libdb-4.0.so

libgdbm.so.2

libhesiod.so.0

liblber.so.2

libldap.so.2

libnsl.so.1

libnsl.so.1(GLIBC_2.0)

libresolv.so.2

libresolv.so.2(GLIBC_2.0)

libresolv.so.2(GLIBC_2.2)

libsasl.so.7

libssl.so.2

This example tests an RPM package file, sendmail-8.12.5-7.i386.rpm, for the requires dependency, in other words, what capabilities the package requires. The sendmail package depends on a lot of other parts of the system, as you can see in the response to the command shown previously. Most of the dependencies are for system libraries (all the dependencies ending in .so or .so.number). This package requires other capabilities (packages in this case). It also requires the chkconfig package at a specific version, version 1.3 or higher, and the bash package at version 2.0 or higher. The sendmail package also requires a particular version of the RPM system (the rpmlib dependency).

Warning

Always check what a package requires before installing the package. You can also use the --test option when trying to install the package to first test whether the installation can proceed. See Chapter 3, Using RPM for details on installing packages and the --test option. The rpm command will perform all these checks for you anyway. Checking in advance, though, with the --test option, helps avoid dependency hell with circular dependencies.

You can also check for what an installed package requires with the --requires option. For example:

rpm -q --requires sendmail

You can use the -R short option in place of the --requires option.

This command returns the same data as the previous command but queries an installed package rather than an RPM package file.

You might assume that applications have the most dependencies, which is true. But even source packages may depend on other packages, often the packages needed to build the sources into an application. For example, the following command lists the capabilities required by a source RPM:

$ rpm -qp --requires telnet-0.17-23.src.rpm

ncurses-devel

Some packages require particular versions of other packages, for example:

rpm -qp --requires xcdroast-0.98a9-18.src.rpm

imlib-devel >= 1.9.13-9

gtk+-devel >= 1.2.10

desktop-file-utils >= 0.2.92

rpmlib(CompressedFileNames) <= 3.0.4-1

This example shows that the xcdroast source package requires the imlib-devel capability (in this case, a package) at version 1.9.13-9 or higher, the gtk+-devel package at version 1.2.10 or higher, and the desktop-file-utils package at version 0.2.92 or higher. This is a more stringent requirement than just depending on the given packages being installed. This RPM is also an older RPM package, based on the requirement for the rpmlib to be prior or equal to 3.0.4-1.

Some packages may require a particular version of the rpmlib, or RPM library. For example, the setup package contains special system configuration files, including the default password file, /etc/passwd.

$ rpm -q --requires setup

rpmlib(PayloadFilesHavePrefix) <= 4.0-1

rpmlib(CompressedFileNames) <= 3.0.4-1

As shown in this example, this package depends only on capabilities of the RPM system itself. The particular requirements shown here specify how the rpm command should treat the package payload, including how the files are listed in the package and what type of compression is used.

Packages require capabilities, and they can provide capabilities for other packages to require. To list the capabilities a package provides, use the --provides option. These capabilities can be arbitrary names, shared libraries (.so files), and the package name itself. The basic syntax is:

rpm –q query_options --provides packages

For example, the tcsh shell package provides two capabilities, at a particular version number, as shown following:

$ rpm -q --provides tcsh

csh = 6.12

tcsh = 6.12-2

Other packages provide a lot more, including shared libraries. The httpd package provides a long list of capabilities, as shown following:

$ rpm -q --provides httpd

webserver

httpd-mmn = 20020628

libapr.so.0

libaprutil.so.0

mod_access.so

mod_actions.so

mod_alias.so

mod_asis.so

mod_auth_anon.so

mod_auth_dbm.so

mod_auth_digest.so

mod_auth.so

mod_autoindex.so

mod_cern_meta.so

mod_cgi.so

mod_dav_fs.so

mod_dav.so

mod_deflate.so

mod_dir.so

mod_env.so

mod_expires.so

mod_headers.so

mod_imap.so

mod_include.so

mod_info.so

mod_log_config.so

mod_mime_magic.so

mod_mime.so

mod_negotiation.so

mod_proxy_connect.so

mod_proxy_ftp.so

mod_proxy_http.so

mod_proxy.so

mod_rewrite.so

mod_setenvif.so

mod_speling.so

mod_status.so

mod_suexec.so

mod_unique_id.so

mod_userdir.so

mod_usertrack.so

mod_vhost_alias.so

httpd = 2.0.40-8

Use the --conflicts option to check what conflicts with a given package. The basic syntax is:

rpm –q query_options --conflicts packages

For example:

# rpm -q --conflicts httpd

thttpd

This command tells you that the httpd package (the Apache Web server) conflicts with the thttpd package. Both packages provide a similar capability. By marking the conflict, the httpd package tells you that you cannot normally install both the httpd and thttpd packages on a system. This information comes from the httpd package, which has an entry in the package that indicates the conflict. The conflict is not guaranteed. These packages may work together, but the creator of the httpd package felt that httpd would not work with the thttpd package and helpfully let us all know.

The RPM system will report on the conflicts and indicate an error if you try to install conflicting packages. The idea of conflicts really gives package creators a way to alert users to potential problems and to tell us that one package likely won’t work with another.

The force options discussed in Chapter 3, Using RPM allow you to override conflicts, if absolutely necessary. In most cases, though, a conflict presents you with the choice to install one or the other of the packages, but not both.

In addition to querying capabilities and requirements of a particular package, you can query the capabilities themselves. This function allows you to check which packages require a given capability.

The --whatrequires option tells the rpm command to report on which packages in the RPM database require a certain capability. The basic syntax is:

rpm –q query_options --whatrequires capability

Some packages are not required by anything:

$ rpm -q --whatrequires tcsh

no package requires tcsh

Note

Don’t worry about the poor tcsh package being lonely. Because other packages do not require this package, you can easily remove the tcsh package without affecting the rest of your system.

This example shows a package name as the capability. Shared libraries are also considered capabilities. You can query on these as well. For example:

$ rpm -q --whatrequires librpm-4.1.so

rpm-4.1-1.06

net-snmp-5.0.1-6

rpm-python-4.1-1.06

rpm-devel-4.1-1.06

rpm-build-4.1-1.06

This example shows that the core RPM library is used by a number of RPM-related packages, along with, oddly enough, the net-snmp system-management package.

The capability you query for must be an explicit capability. For example, you will get different results if you query for the bash package or the command, /bin/bash. If you query for the bash package, you will see the packages that explicitly require the capability bash. For example:

$ rpm -q --whatrequires bash

gpm-1.19.3-20

info-4.0b-3

initscripts-6.40-1

sendmail-8.11.6-3

sysklogd-1.4.1-4

vixie-cron-3.0.1-63

ypbind-1.8-1

ypserv-1.3.12-2

If you instead query for the capability /bin/bash, that is, the file /bin/bash, you will see a different list of packages. For example:

$ rpm -q --whatrequires /bin/bash

apmd-3.0final-34

at-3.1.8-20

autofs-3.1.7-21

autofs-3.1.7-21

bash-2.05-8

bind-9.1.3-4

cipe-1.4.5-6

crontabs-1.10-1

dialog-0.9a-5

gpm-1.19.3-20

hotplug-2001_04_24-11

initscripts-6.40-1

ipchains-1.3.10-10

iproute-2.2.4-14

kudzu-0.99.23-1

logwatch-2.1.1-3

man-1.5i2-6

mkbootdisk-1.4.2-3

mkinitrd-3.2.6-1

mutt-1.2.5i-17

openssh-server-3.1p1-2

pine-4.44-1.72.0

rpm-build-4.0.3-1.03

rusers-server-0.17-12

sendmail-8.11.6-3

shapecfg-2.2.12-7

sharutils-4.2.1-8

sysklogd-1.4.1-4

tetex-1.0.7-30

ucd-snmp-4.2.1-7

vixie-cron-3.0.1-63

xinetd-2.3.3-1

ypbind-1.8-1

ypserv-1.3.12-2

There is no short form for the --whatrequires option.

Other capabilities, especially system-level shared libraries, are used by a large number of packages. For example:

# rpm -q --whatrequires libcrypt.so.1 | sort

autofs-3.1.7-21

cvs-1.11.1p1-3

cyrus-sasl-1.5.24-23

cyrus-sasl-devel-1.5.24-23

cyrus-sasl-plain-1.5.24-23

fetchmail-5.9.0-1

ircii-4.4Z-7

krbafs-1.0.9-2

nss_ldap-172-2

openldap12-1.2.12-4

openldap-2.0.11-13

openldap-clients-2.0.11-13

pam-0.75-19

pam_krb5-1.46-1

passwd-0.64.1-7

perl-5.6.0-17

pine-4.44-1.72.0

pwdb-0.61.1-3

python-1.5.2-35

rsh-0.17-5

rsh-server-0.17-5

screen-3.9.9-3

sendmail-8.11.6-3

shadow-utils-20000902-4

sh-utils-2.0.11-5

SysVinit-2.78-19

tcsh-6.10-6

util-linux-2.11f-17

vim-enhanced-5.8-7

wu-ftpd-2.6.1-20

xinetd-2.3.3-1

ypserv-1.3.12-2

yp-tools-2.5-1

Quite a few packages require encryption and decryption (the purpose of this library), making this library crucial to operating the system. Many of the packages listed here are in turn depended on by even more packages.

To help trace back capabilities, you can combine the queries. For example:

$ rpm -q --provides sendmail

smtpdaemon

sendmail = 8.11.6-3

$ rpm -q --whatrequires smtpdaemon

fetchmail-5.9.0-1

mutt-1.2.5i-17

The first command lists the capabilities that the sendmail package provides, including the generic capability of smtpdaemon. You can then list which packages require this particular capability, as shown in the second command. This is a big help for wading through a mess of packages depending on packages depending on yet more packages.

To complete the circle, you can query for which package provides a certain capability. This knowledge allows you to trace a requirement back to the package that provides it.

The --whatprovides option tells the rpm command to list the capabilities a package provides. Use the --whatprovides option with the –q, or query, option to the rpm command. (There is no short form for the --whatrprovides option.)

The basic syntax follows:

rpm –q --whatprovides capability

For example, to query what package provides the capability webserver, use the following command:

$ rpm -q --whatprovides webserver

httpd-2.0.40-8

In this case, the capability is identified by an arbitrary string, webserver. This is a generic name for a given capability, serving Web pages.

You can also trace individual files using the --whatprovides option. For example:

$ rpm -q --whatprovides /etc/skel/.bashrc

bash-2.05-8

Note

The rpm –qf command, covered in the last chapter, is an easier way to get to the same information when tracking which package provides a particular file. For example:

rpm -qf /etc/skel/.bashrc

bash-2.05-8

If you are querying particular files, use rpm –qf. If you are querying capabilities, use --whatprovides.

Whenever you install or remove packages, the RPM system assigns a transaction and a transaction ID to the set of packages. You can then perform operations on the packages that share the same ID, including rolling back the transaction.

Note

Rollbacks work only for package upgrades with the 4.1 version of the RPM system, not package installs

The RPM system saves an image of the RPM package header for each package installed or removed. You can use this image, along with RPM transaction IDs, to back out of transactions should something go wrong when setting up your system.

The main advantage of transactions with RPM, though, is the fact that the rpm command automatically sets up a transaction for all the packages on each command line and does not perform the operation if any package fails. This ability to automatically set up transactions for each call to the rpm command eliminates many errors when working with packages.

Use a transaction when you need to be sure that a set of packages install properly.

With RPM, backing out of a transaction involves two operations: rolling back the transaction and reinstalling the former packages to restore the previous system state. In the simplest case, the rpm command handles all the tasks for you. If you try to install, upgrade, or remove multiple packages and any package fails, the rpm command will restore the system state for you.

This automatic support for transactions is a great help to system administrators, but it only applies when you first install, upgrade, or remove the packages. If you have upgraded your system and later discover problems, then you can also use the --rollback option to roll the system back from a set of upgrades, in a limited set of circumstances.

The rpm command gives every package installed a transaction ID. The transaction ID is a Unix time stamp (number of seconds since January 1, 1970). You can then perform some operations on packages based on the transaction ID.

Note

The fact that a transaction ID uses a Unix timestamp may change in the future.

All the packages installed at the same time are given the same transaction ID. This means that you can perform operations on a set of packages, the packages that were installed together.

But there’s also a downside to this. All the packages installed when you first installed or upgraded your Linux system are given the same transaction ID. This means you cannot selectively act on these packages using the transaction ID, because you will likely get far more packages than you want to work on.

The --rollback option to the rpm command allows you to roll back upgrades based on a time. Use a command like the following:

# rpm –U --rollback "3 months ago"

The --rollback option is very limited in what it can do. The --rollback option works only for packages that have been upgraded. You cannot rollback the initial installation of a package. This is to prevent you from accidentally rolling back all packages.

The --rollback option works best if you want to restore the system to a previous state, prior to performing any other RPM operations. That is, soon after you upgraded a package and decide that it isn’t working right. If you have modified the RPM system after performing the transaction you want to rollback, there may be unintended consequences if any new package depends on the packages you want to roll back. In addition, the --rollback option only works in limited situations but does not always report when these conditions are not met. The rpm command may simply do nothing, or it may remove packages you do not expect.

Warning

Before running the --rollback option, backup your RPM database as described in Chapter 4, Using the RPM Database .

Because of all these limitations, rollbacks do not work in all situations. In place of the --rollback option, you can use the query shortcuts introduced in Chapter 4, Using the RPM Database and find the packages you have installed recently (if that is what you want to roll back). In this case, you can use the rpm command to remove the packages you want to get rid of and reinstall the packages you want to restore.

In many cases, this manual approach is safest, and you will have a clearer understanding about what was installed or upgraded on your system.

One popular free tool for locating RPMs is rpmfind, written by Daniel Veillard. This tool provides a command-line utility that can search for packages by name or description, displaying or optionally downloading any matching packages it finds. It can even provide a list of the dependencies that those matching packages require to run and can download those required dependencies as well.

When searching for packages, rpmfind can search both the software already installed on the local system and remote databases, including the databases located at http://rpmfind.net/.

Note

The databases at http://rpmfind.net/ are, in turn, created by another utility: rpm2html. Both are covered in the sections following.

Commonly, rpmfind is used to search for packages by name, though it can be used to search package descriptions for key words. For example, I might want to find new e-mail clients to install on my system. I happen to know that one popular Linux e-mail client is Ximian’s evolution, so I search for that.

The basic syntax for rpmfind follows:

rpmfind package_name

For example, to search for evolution, use a command like the following:

$ rpmfind evolution

Resource evolution already installed

$

Before accessing the Internet, rpmfind searches my local system and finds that I already have evolution installed, so it does not even bother searching for copies to download. It looks like I’m forgetful, not remembering that I already have evolution installed. At this point, I might realize that I already have the software I need, or I might decide to search for a similar application, such as exmh, another popular Unix e-mail client.

To search for exmh (which in this example has not been installed), use a command like the following:

$ rpmfind exmh

Installing exmh will require 7301 KBytes

### To Transfer:

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0.4-9.i3

86.rpm

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2.4-2.noarch.rpm

Do you want to download these files to /tmp [Y/n/a/i] ? : a

transferring

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//nmh-1.0.4-9.i386.rpm

saving to /tmp/nmh-1.0.4-9.i386.rpm

transferring

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//exmh-2.4-2.noarch.rpm

saving to /tmp/exmh-2.4-2.noarch.rpm

rpm -U /tmp/nmh-1.0.4-9.i386.rpm /tmp/exmh-2.4-2.noarch.rpm

$

Here, rpmfind searches my local system for exmh. Since exmh is not installed there, rpmfind searches the databases at http://rpmfind.net/ and does two things: it finds exmh, and it learns that exmh depends upon another package: nmh. After double-checking and learning that nmh is not installed on my local system, rpmfind gives me a choice regarding whether I should download both of those packages; rpmfind gives me four possible answers:

Do you want to download these files to /tmp [Y/n/a/i] ? : a

My possible answers were:

YYes, do download the files.

NNo, do not download the files.

AGet all. By default, run in Automatic mode, trying to upgrade packages after they are downloaded

IInstall packages after download.

Note

Any user can download packages, but usually only the root user can install packages. Unless you are logged in as root, rpmfind will likely fail to install the downloaded RPMs.

Because I select the "a" answer, rpmfind downloads all necessary packages to /tmp and tries to upgrade the packages automatically by running the following command:

rpm -U /tmp/nmh-1.0.4-9.i386.rpm /tmp/exmh-2.4-2.noarch.rpm

In this case, the rpm -U command silently fails, since I am not running it as root and do not have permission to install software.

If the name of a package is unknown, rpmfind also supports searching by keywords. The --apropos pattern option tells rpmfind to search through all package descriptions in the databases for the pattern. If I do not know the names of any e-mail clients, I might use this code for my search:

$ rpmfind --apropos "mail client"

Searching the RPM catalog for mail client ...

1:

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//netscape-communicator-4.78-2.i386.rpm

netscape-communicator : A Web browser, news reader and e-mail client.

2:

ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS//sylpheed-0.5.0-3.i386.rpm

sylpheed : A GTK+ based, lightweight, and fast email client.

<snip>

364: ftp://ftp.pld.org.pl/PLD-1.0/dists/ra/PLD/SRPMS/SRPMS/sylpheed-0.7.4-1.src.rpm

sylpheed : GTK+ based fast e-mail client

From my search, rpmfind returns the following output (with most of the entries edited out for space):

Found 364 packages related to mail client

$

With this command, rpmfind connects to the databases at http://rpmfind.net/ and returns the location of all packages whose description contains the text “mail client”. Notice that 364 packages are found; there are lots of e-mail clients available for Linux! That number, however, is slightly misleading. Some of the packages found are prepared for the distribution I am running (Red Hat Linux version 7.2), but others are not. Result #364, for example, appears to be the Polish(ed) Linux Distribution 1.0 package of sylpheed, the same software offered to me packaged for my Red Hat Linux version 7.2 system in Result #2.

Warning

Use caution when working with rpmfind. By default, it connects to the databases on the server http://rpmfind.net/ and queries them. These databases are indexes of all RPM-based distributions, and of all versions of each RPM-based distribution, and of all architectures, and of both source and binary RPMs for all these distributions!

To help you avoid being overwhelmed with results (such as the 364 results I obtain when I search for “mail client”), options are available to fine-tune rpmfind’s searches in various ways. Common options are presented in Table 8-1.

Table 8-1SEARCH OPTIONS FOR rpmfind

The rpmfind databases that rpmfind searches are created using the utility rpm2html. If you desire, rpm2html can be used to set up a local mirror of the databases at rpmfind.net or to make a custom database of locally available RPMs for in-house use.

rpm2html

The rpm2html utility generates HTML Web pages that describe RPM packages. Very simple in concept, rpm2html has proven very useful over the years.

With rpm2html, each package is displayed as a single HTML page that describes the package using information much like that returned by the rpm -qi command, covered in Chapter 3, Using RPM . The HTML page also lists the capabilities the package requires and those it provides. This shows the needed dependency information. Finally, the page includes a download link to download the RPM file.

All packages of the same name, such as the exmh e-mail client, are collected on summary pages. The summary page tries to list all RPMs for all Linux distributions that provide the given package. For exmh, for example, the database as of this writing includes 71 versions of the exmh package, for Conectiva Linux, Mandrake Linux, Yellow Dog PowerPC Linux, and so on. The summary page also links to the URL in the RPMs that is listed as the home page for the application.

Used together with its database, rpm2html provides a powerful RPM-centric search engine. You can find more on rpm2html at rpmfind.net/linux/rpm2html/ or just access an RPM search site such as rpmfind.net.

In addition to rpm2html, the program pdbv creates a set of cross-linked HTML files that list the packages on your system. Pdbv doesn’t support searching and wasn’t built as a front end for search sites, so it is simpler than rpm2html. Instead, pdbv just creates a set of HTML pages that list data that you can query with the rpm command, including the package descriptions, the capabilities required and provided, as well as all the files in the package.

The primary advantage of pdbv is that it runs relatively quickly to provide you a snapshot of your system.

In addition to the command-line RPM search tools, a number of Web sites provide handy front ends to databases of available packages. These Web sites make it easy to query for packages and also provide snapshots of what is happening in Linux development, especially with the sites that list recently created RPMs.

The following sections list some of the more popular sites.

Note

As with anything on the Internet, sites come and go. I’ve used rpmfind.net for years, but it is always possible that any of these sites may suddenly disappear.

Nautilus provides a visually appealing file manager that is part of the GNOME desktop. Nautilus acts as a normal file manager that can also display some types of files, such as images. In addition, you can launch applications that Nautilus knows about when you double click files. Figure 8-1 shows Nautilus in action.

Insert 54965-0 fg0801.tif

Figure 8-1: Browsing RPM files with Nautilus.

If you double click an RPM file (a file ending with the extension .rpm), Nautilus will install the RPM file. First, though, Nautilus will prompt you for the root password, since you must be logged in as root to install RPMs. Figure 8-2 shows Nautilus prompting for a password.

Insert 54965-0 fg0802.tif

Figure 8-2: You must be logged in as root to install packages.

After some time processing, you should see the Completed System Preparation window, as shown in Figure 8-3.

Insert 54965-0 fg0803.tif

Figure 8-3: Installing RPM files with Nautilus.

When you install RPMs with Nautilus, it really runs the Red Hat Package Management tool.

Note

Nautilus only supports RPM functionality starting with Red Hat Linux 8.0. This functionality may not be supported in other versions of Linux.

The redhat-config-packages application (say that three times fast) comes new with Red Hat Linux 8.0. You can use the Python program in this package to manage the packages that come with Red Hat Linux, using an interface that is very similar to the Red Hat Linux installation program. This similarity may make it easier for many users to manage their packages, although I found the program a bit short on explanations.

To run this program, you first have to do a bit of searching to find it. It appears under the System Settings menu from the main Red Hat Start menu under the default Bluecurve desktop. Select the Packages choice to launch this program. You can also start the program from the command line with the following command:

# redhat-config-packages

This program takes a long time to read in all the information and start up. Once started, the interface provides the same categories and much the same look as the Red Hat Linux installer, as shown in Figure 8-4.

Insert 54965-0 fg0804.tif

Figure 8-4: The redhat-config-packages package manager.

The packages tool divides the packages into groups. Inside each group, the packages are divided into two sets: standard and extra packages. (Red Hat places the packages into these categories, striving to make a reasonable division among the many packages that come with Linux.) If you click the check box for a group, the tool will queue up all the standard packages within that group for installation. If you uncheck a check box for a group that was checked before, the tool will queue up all the installed packages in that group for removal, both standard and extra.

Warning

Installing or removing all the packages in a group when you don’t know what is in the group is not a good idea.

To delve into a group and see what is inside, click the Details link associated with that group. Clicking the Details link will bring up a window where you can check individual packages for installation and uncheck individual packages for removal. Figure 8-5 shows the details of the Web Server group.

Insert 54965-0 fg0805.tif

Figure 8-5: Package details for the Web Server group.

Once you have selected all the packages you want to install, and unselected all the packages you want to remove, click the Update button on the main window of the package-management tool. After some processing, you should see the Completed System Preparation window, which lists the amount of disk space required for the new packages and the amount that will be freed by the packages to be removed. Figure 8-6 shows this window.

Insert 54965-0 fg0806.tif

Figure 8-6: The Completed Systems Preparation window.

Click the Show Details button to see a complete list of all the packages to be installed and removed.

Warning

If the packages you choose to install depend on any other packages, the package-management tool will automatically add these packages to the list to be installed. More important, if any packages installed on your system depend on any of the packages you have marked for removal, the tool will add those additional installed packages to the list to be removed. Always examine the Show Details window to see what will really be installed and removed.

Figure 8-7 shows the window with the package details.

Insert 54965-0 fg0807.tif

Figure 8-7: The Show Details window.

The package-management tool worries me. It has an absolutely beautiful look, but it tries to do too much, especially when removing packages. Always use this program with care. I much prefer to just launch it with single packages from the Nautilus file manager.

One popular graphical RPM management tool is KPackage, supplied with the KDE Desktop. (You can find this product at www.kde.org). KPackage offers basic package-management functionality. It can install and uninstall packages and display information about installed and available packages’ contents and headers. In addition, KPackage supports a wide variety of package formats in addition to RPMs. Be aware, however, that KPackage cannot automatically resolve dependencies. When you are installing new software packages, any dependencies required by that software must first be manually installed.

When started, KPackage presents a basic two-paned interface.

The left-hand panel lists Installed packages already on the system, Updated packages available to update the system, New packages available for installation, and All packages (both installed and available for installation/upgrade). When displaying package lists, KPackage organizes the displayed packages into categories based on their group.

The right-hand panel lists information about the package currently selected in the left-hand panel. Information displayed includes the package Properties, listing the package’s header, and the File List of files that package owns. Figure 8-8 shows this panel on the right side of the interface.

Note: old fig 8-8 deleted; renumber all remaining to match. Chapter has been changed to reflect deletion.

Insert 54965-0 fg0808.tif

Figure 8-8: The KPackage interface, showing properties of the selected package

After packages have been selected, they can be installed or uninstalled, as shown in Figure 8-9

Insert 54965-0 fg0809.tif

Figure 8-9: KPackage installs the selected package on your command.

In addition to supporting RPM, KPackage can be used on systems that use other packaging methods. Current versions of KPackage support Debian’s dpkg and the BSD projects’ package formats as well as RPM.

The GNOME Desktop (www.gnome.org) provides another graphical RPM-management tool, Gnome-RPM. Also known as gnorpm, Gnome-RPM is very similar to KPackage in terms of its basic functionality, although Gnome-RPM can manage only RPMs.

When started, Gnome-RPM presents a hierarchical list of installed packages, arranged by group, as shown in Figure 8-10:

Insert 54965-0 fg0810.tif

Figure 8-10: The main Gnome-RPM window.

After a specific package has been selected, you can can query to see its details, as shown in Figure 8-11:

Insert 54965-0 fg0811.tif

Figure 78-11: Querying the details for a package.

With Gnome-RPM, you can also filter the list of packages to see only the list of uninstalled RPMs, as shown in Figure 8-12.

Insert 54965-0 fg0812.tif

Figure 78-12: Filtering to see only the uninstalled packages.

Like KPackage, when installing new software, Gnome-RPM lacks the ability to automatically install any dependencies needed by that software.

One popular tool to lessen the work involved with administering RPM-based systems is AutoRPM. Written by Kirk Bauer, AutoRPM is available under a free MIT-style license from the home page www.autorpm.org.

A Perl script, AutoRPM provides several features that make it especially useful. First, it can create local mirrors of RPM repositories. Typically, this feature might be used to create a local archive of errata for a Linux distribution. AutoRPM can also compare all currently installed RPMs against a list stored elsewhere. This list can be either an FTP site or a directory on the local system. After comparing the currently-installed RPMs against the list, AutoRPM can then update any packages from the list site that are newer than what is installed on the local system. This way, you can define one site or directory as the master site of the package versions that need to get installed on all systems and let AutoRPM ensure that all computers on your network are up to date.

Together, these two functions make AutoRPM very convenient for keeping systems current with all errata the vendor releases. They can also be used to create a method of distributing software to a network of systems. For example, every workstation in the department can run AutoRPM, configured to watch a common directory on a local NFS server. Installing new software on every workstation in the department occurs simply by copying an RPM of the software into that directory, letting AutoRPM do the rest of the work.

AutoRPM is designed to be used both automatically from cron and interactively from the command line. By default, AutoRPM runs via a nightly cron job and downloads all updates for software currently installed on the system. It then stores these updates in a local directory, typically /var/spool/autorpm, and e-mails an administrator a notification on the new updates. The administrator can then log onto the system and manually install the updates using the rpm command. AutoRPM can also be easily configured to install automatically any new packages it downloads. If AutoRPM is so configured, the system administrator does not even have to log in and run rpm commands to keep the system up-to-date!

In interactive mode, AutoRPM provides a basic set of commands, listed in Table 8-2.

Table 8-2Basic AutoRPM commands

The commands that manipulate RPMs (such as install, used to install an RPM) accept as arguments both paths to RPM files on the local system, and also URLs pointing to RPMs on an FTP repository. In addition, they support wild cards and directory accesses, so a command such as install ftp://ftp.redhat.com/pub/redhat/linux/updates/current/* can be used to install all errata for the current release of Red Hat Linux.

In addition to interactive mode, AutoRPM provides a noninteractive mode, suitable for use through cron. In noninteractive mode, invoked by the command autorpm --notty auto, AutoRPM consults the configuration file /etc/autorpm.conf to decide what to do. By default, /etc/autorpm.d/autorpm.conf is configured to download, but not automatically install, all errata for the release of Red Hat Linux running on the local system. Editing this file makes it possible to use AutoRPM to download all errata — or errata for other Linux distributions — or to install errata automatically once downloaded.

Typically, AutoRPM is used to automate installation of errata updates and other software on all machines in the enterprise. To do this, one machine is selected to serve as a file server. On it, AutoRPM is configured to download and install all errata. The directory where the errata are stored on that server is then exported to the other machines in the enterprise, which also run AutoRPM. These other machines have AutoRPM configured to install all files that the file server exports. Using a configuration such as this, all machines in the enterprise get all security updates automatically installed. In addition, installing a desired new software application on all hosts in the enterprise can be done simply by copying an RPM of the application onto the file server, making it available for the AutoRPM nightly updates to access and install automatically.

AutoUpdate, written by Gerald Teschl, is another Perl script that can be used to automate RPM downloads or installations. Available freely under the terms of the GNU GPL from www.mat.univie.ac.at/~gerald/ftp/autoupdate, AutoUpdate is very similar to AutoRPM in terms of both functionality and potential applications. Unlike AutoRPM, AutoUpdate offers no interactive capability. However, AutoUpdate does have the capability to manage dependencies correctly; when using AutoUpdate to install software that depends upon other uninstalled software, AutoUpdate attempts to resolve the dependencies and to install all necessary software packages.

AutoUpdate bases all decisions about what software to download or install upon its configuration file, /etc/autoupdate.d/autoupdate.conf. By default, AutoUpdate provides several additional configuration files pre-defined for downloading updates for the most popular RPM-based Linux distributions (Red Hat Linux, Mandrake Linux, Caldera/SCO OpenLinux, and SUSE Linux). The autoupdate.conf file can be modified to configure AutoUpdate to install software automatically.

Table 8-3 lists the five commands that compose all the utilities provided by AutoUpdate:

Table 8-3AutoUpdate commands

These tools can access remote files by using a variety of methods. Like AutoRPM, AutoUptodate can download files if given an FTP URL. AutoUpdate can also access HTTP URLs and local files. Its additional dependency-tracking functionality and support for additional file-access methods make it suitable for use in cases where AutoRPM might be inappropriate. AutoUpdate cannot be used interactively, however, making AutoRPM more useful for nonautomated purposes.

Some vendors of RPM-based Linux distributions also provide utilities that can help with management of the distributions they create. Red Hat has created two complementary products, the Red Hat Network (RHN) and up2date, which together provide much the same functionality for managing Red Hat Linux installations as tools such as AutoUpdate and AutoRPM, as well as offering more advanced features.

Red Hat Network is a subscription-based service offered by Red Hat Red Hat Network makes software available for installation via the network. (A free evaluation is also available.) After registering machines with Red Hat Network, administrators can pull updates or new software for installation to those registered machines. In addition, administrators have access to a Web-based administrative console from which they can view the systems they manage and can push software out to those systems.

Red Hat offers two tiers of access to Red Hat Network. Basic Service subscriptions to Red Hat Network provide the ability to manage single systems. Multiple machines can be subscribed by the same administrator for Basic Service level Red Hat Network access, but they must all be managed independently. The administrator must push out errata to each machine separately. Workgroup Service subscriptions provide the same functionality as Basic Service subscriptions, but they also provide the ability to group multiple machines for simultaneous administration. All errata updates for all machines subscribed to Workgroup Service can be pushed out by a single action, for example. Furthermore, Workgroup Service subscriptions can allow management by multiple administrators if desired, making it possible for large organizations to share responsibilities among administrators.

When using Red Hat Network to manage machines with Workgroup Service subscriptions, Red Hat also offers two optional services: Red Hat Network Proxy Server and Red Hat Network Satellite. The Red Hat Network Proxy Server is, as its name suggests, a proxy server for the Red Hat Network. Using it, errata pushed out via Red Hat Network is downloaded by the organization (only once) to a central server in-house. All machines in that organization subscribed to Red Hat Network get their updated software from that in-house proxy server, significantly reducing the network bandwidth requirements needed to keep large organizations up to date.

In addition, the Red Hat Network Proxy Server can be used to provide all subscribed machines with software not provided with Red Hat Linux. Custom “channels” of supplemental software can be created on the Proxy Server, and machines can be subscribed to those channels as desired. Using this feature, different departments in the organization with different software needs can create independent channels for each department, ensuring that machines get only the software needed on them. Similarly, distinct channels can be created for separate classes of machines, ensuring that servers get only software appropriate for server machines and that desktops only get only software that desktop machines need.

The Red Hat Network is normally centrally administered through Red Hat. Machines subscribed to the Red Hat Network have a system profile on file with Red Hat that details the system’s essential configuration information (what software is installed on it, what CPU architecture it contains, and so forth) needed to determine which software errata are appropriate for that system. Similarly, the Web console through which machines subscribed to Red Hat Network can be administered is also located on a Red Hat server. Customers wishing to use Red Hat Network services, but not wanting the dependency upon Internet access to Red Hat, can create an in-house Red Hat Network by using the Red Hat Network Satellite. This solution is often practical for customers who need to keep system information confidential or for customers whose systems are not able to access the Internet.

Red Hat provides several interfaces for administering machines subscribed to the Red Hat Network. A Web-management console is available at https://rhn.redhat.com/. Administrators of machines subscribed to any level of the Red Hat Network can simply log into this Web site and perform a variety of package-management operations from their Web browsers. In addition to viewing other things, administrators can see what software is currently installed, select and install Red Hat Linux errata or new software, or schedule a time for automatic installation of Red Hat Linux errata.

When using Red Hat Network, rhnsd is a client-side daemon that should be run on subscribed systems. It periodically launches a helper utility, rhn_check, which connects to the Red Hat Network servers and checks for any actions (such as a scheduled installation of errata) that an administrator has selected in the Web console. If any actions have been scheduled for that client machine, rhn_check on the client initiates those actions. By default, rhnsd runs rhn_check every two hours. This time can be increased to check for configuration changes as frequently as every hour if necessary.

In addition, Red Hat provides client-side tools that can be used in a more interactive fashion to connect to the Red Hat Network from subscribed systems. The up2date program provides a graphical and command-line tool that can be used to install packages from Red Hat Network servers. When installing a new package, up2date automatically installs any necessary dependencies the package requires, making it a very convenient tool for adding software to the system. up2date can also be run in update mode, thus telling it to install all updates available for the software already installed on the system. Commonly used options with up2date include those listed in Table 8-4.

Table 8-4Options for the up2date command

The up2date command, the Red Hat Network client software, is open-source software released by Red Hat under the terms of the GNU GPL. Red Hat Network Proxy Server and Red Hat Network Satellite, the server applications with which up2date interacts, are not freely available, open-source applications. For this reason, an effort is underway to develop servers available under the terms of the GNU GPL that can be used with up2date clients. The main program in this effort is called current, which refers to keeping your systems current.

The current server can be downloaded from http://current.tigris.org. Although not yet as functional as Red Hat Network Proxy Server or Red Hat Network Satellite, current can already be used to create a RPM repository from which up2date-using clients can retrieve and install software. More advanced features, such as support for multiple “channels” of software, will be added to current in future releases.

Mandrake provides a set of software similar to the combination of up2date and Red Hat Network or current that can be used with the Mandrake Linux distribution. Links to the source code for the Mandrake applications can be found at www.linux-mandrake.com/cooker/urpmi.html. This suite of applications is typically referred to as urpmi and includes both the urpmi command and several helper applications. urpmi itself is a command that acts as a wrapper around the rpm command. When given the name of a package to install, urpmi determines what dependencies, if any, required by the application are not already resolved and offers to install the packages necessary to fulfill those dependencies.

When installing packages, urpmi can install from a variety of sources: FTP repositories, Web servers, local or NFS directories, and removable media such as CD-ROMs. The helper application urpmi.addmedia is used to add package sources, and the corresponding utility urpmi.removemedia is used to remove package sources no longer desired.

Mandrake’s urpmi program includes one very handy feature. It comes with an autoirpm helper utility that can be used to configure the system to install packages on demand. This is done by running the command autoirpm.update-all, an application that scans all packages available for installation via urpmi. For every package available through urpmi, autoirpm.update-all determines what executable programs it provides, and it creates a symbolic link from that executable’s name to the autoirpm script. Attempting to execute such a symbolic link executes autoirpm, which in turn automatically uses urpmi to install the associated package. The result: on-demand installation of packages when users on the system attempt to execute the programs that those packages provide.

Two different interfaces are available for urpmi. The urpmi command starts up urpmi in command-line mode, and the gurpmi command (or urpmi --X) starts urpmi in a graphical X-based mode. In addition, Mandrake provides a more full-featured graphical application: RpmDrake. RpmDrake provides the same package-management capabilities as urpmi, including the capability to install all required dependencies whenever installing any new packages.

Another free RPM management utility is available that provides many of the features of both vendor solutions such as up2date or urpmi and of third-party utilities such as autoUpdate or KPackage. This tool is apt-rpm, a port of the Debian Project’s excellent apt (Advanced Package Tool) software.

The Debian Project (www.debian.org/) is a nonprofit volunteer group that develops a Linux distribution, Debian GNU/Linux. The group uses a different package format, dpkg, which was developed independently of and simultaneous to Red Hat’s creation of RPM. The two formats, dpkg and RPM, are very similar in terms of utility and functionality. In addition to having created a package format, the Debian Project later developed a collection of software, apt, which could be used to manage and install dpkg-format software. And, since Debian distributions are typically installed over the Internet, this apt software has to supply advanced distributed package management functionality.

In many respects, Debian’s implementation of apt is very similar to the functionality provided by Red Hat’s up2date/Red Hat Network products or Mandrake’s urpmi software. On Debian systems, apt is a client tool used to select and install new software packages or to update existing packages already installed on the system. To do this, it accesses a user-configured list of resources that supply new packages; these resources are typically the Debian Project’s FTP or Web servers, though they can also be CD-ROMs or local or remote file systems. For apt to be able to download packages from a resource such as a CD-ROM or an FTP server, that resource must supply two things: the software packages being downloaded and a database supplying metadata about all the packages in the repository. These resource databases are essential for apt to operate. For this reason, apt can only be used to update systems from apt-capable repositories.

Although apt was created by the Debian Project and designed for dpkg-format software packages, nothing about apt requires that it inherently be usable only with dpkg-format packages. Because of this, and because of its powerful capabilities, Conectiva, a Brazilian Linux distribution vendor (www.conectiva.com), extended apt to support management of RPM packages in addition to dpkg packages. Conectiva’s work, commonly referred to as apt-rpm, makes the apt client software available for use on any RPM-based Linux distribution. Conectiva also provides its customers with access to apt-capable FTP servers. A related project, apt4rpm (http://apt4rpm.sourceforge.net/), supplies the necessary utilities that can be used to make any RPM repository apt-capable. By creating apt-capable servers using apt4rpm and then installing apt-rpm on the client systems, any RPM-based distribution, such as Red Hat Linux, Mandrake Linux, Caldera/SCO OpenLinux, or SUSE Linux, can then be easily managed using apt.

Note

The freshrpms.net site, mentioned previously, provides a touted apt repository.

Administrators managing multiple dispersed machines as well as those used to Debian administration often find it useful to configure their machines to use apt; its dependency tracking is far better than any other tool, except for Red Hat’s up2date/RHN combination. To use apt, administrators must install it on their machines and have access to an apt-capable RPM repository for the distribution they use. Several public FTP sites that support apt are now available for most of the major RPM-based distributions. Also, the administrator can create another apt-capable repository.

Configuration of machines to use apt is simple. The apt and libapt RPMs simply need to be installed. Although binaries are sometimes available, the best success can usually be obtained by building binary RPMs from the latest Conectiva apt SRPM (source RPM), available at ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/.

Once apt and libapt RPMs are installed, the sources.list file in /etc/apt needs to be modified to reference the apt-capable software site that will be used. For example, to configure a machine to access the apt-capable Red Hat Linux 7.2 software distributed by the Tuxfamily.org server, the /etc/apt/sources.list file needs to list:

rpm http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os

rpm http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os

These two lines, respectively, access the Red Hat Linux 7.2 and Red Hat Linux 7.2 errata RPMs being served by the system apt-rpm.tuxfamily.org. If you also want access to source RPMs, the following lines are necessary as well.

rpm-src http://apt-rpm.tuxfamily.org/apt redhat-7.2-i386/redhat os

rpm-src http://apt-rpm.tuxfamily.org/apt redhat-updates-7.2/redhat os

In addition to, or instead of, using public apt-capable servers, many sites want to create their own apt servers. If apt is being used to manage all the machines in the enterprise, a custom apt server might be needed that contains apt-accessible RPMs of all the custom software used in the enterprise. This can be done using the tools provided by the apt4rpm package (http://apt4rpm.sourceforge.net).

Once apt has been installed on clients, and the clients have been configured to access an apt-capable server, keeping systems updated is simple. The command apt-get update updates the client system’s apt database of available software, after which the command apt-get upgrade upgrades all currently installed software to the latest version available in the software repository. By listing a site that provides vendor errata updates in /etc/apt/sources.list and then setting up a nightly cron job to run the apt-get upgrade command, administrators can be sure that client systems always have the latest errata installed. You can use a similar technique to ensure that all client systems are always up to date with the latest custom in-house applications. To do this, set up your own apt server and ensure that the latest custom applications are placed on the apt server.

In addition, apt simplifies interactive installation of RPMs on systems that are using it. The command apt-get install package retrieves the named RPM from the apt-capable software repository and installs it. If the package requires any dependencies that are not already resolved, apt will ask for confirmation, then download and install the package and all dependencies. Similarly, apt-get remove package uninstalls the named RPM. If any other packages depend on it, it will prompt for confirmation, then uninstall the named RPM and all of its dependencies.

In addition to these command-line utilities, several graphical front-end tools for manipulating apt are currently being ported for use with apt-rpm. Because of its ease of use for automating installation of system errata and necessary custom software, and because of the excellent dependency tracking it provides for interactive installation and uninstallation of software, apt-rpm can be excellent for managing RPM-based systems.

Also similar to the Debian apt tool, a utility called the poldek works like apt-get. The poldek was designed to quickly scan through dependencies and install a number of packages at once. You can specify all the packages to install in a file.

The poldek automatically downloads any needed dependencies. The poldek can download files over the Internet and also help create the packages for storage on CD-ROMs. The poldek optimizes the set of packages to reduce the number of times users have to switch CDs.

Cross Reference

For more on the poldek, see poldek.pld.org.pl.

The first step in the entire RPM-building process is simply to decide exactly what you want to make into an RPM. Is this an application, a programming library, a set of system configuration files, or a documentation package? If this is an application, is it customized or patched? Think these issues over and decide what you want to package as an RPM.

In most cases, you want to create both a source package and a binary package containing the built sources. You need a binary package because that holds the RPM you want to install on other systems. You need the source package so you can recreate the binary package at any time. And, if the sources get updated, you can quickly make a new binary RPM from the updated sources if you have already defined a source RPM.

Most packages start with a source RPM, although you have the option to skip making a source RPM. It is a good idea to make the source RPM, however, because it makes it easier to reproduce the final binary RPM. Once of the key goals of the RPM system is to allow for reproducible builds, and making source RPMs is just one step to help towards this goal.

Creating a source RPM also allows you to transfer the entire set of sources for a package to another system, since the source RPM is just one file and it contains all the program sources along with the instructions, called a spec file, for building the binary RPM. Furthermore, creating a source RPM makes it easier to create binary RPMs on different processor architectures or different versions of Linux.

Note

Not all programs are portable to multiple-processor architectures. But many Linux programs can simply be recompiled on another architecture to make a binary program for that architecture. That's because there are a lot of common APIs for Linux applications and because most programs are not processor dependent. This is not true of all programs, so your mileage may vary.

Source packages are not that hard to make, and they provide a single package, and single file, that holds all the sources necessary to build your binary package. In addition, once you have a source RPM, it is very easy to build a binary RPM.

Binary packages are likely the real reason you want to make an RPM. You can package an application, a programming library, or almost anything you want. Armed with a binary RPM, you can transfer one file to another machine and install the application there, taking full advantage of the RPM system.

Whether you are writing your own software or merely packaging software found elsewhere, the next step is to gather the software you want to bundle into an RPM. This includes the applications or libraries you want to package, as well as the program source code.

In general, you’ll be doing one of three things:

*Packaging your own software

*Packaging someone else’s software

*Packaging someone else’s stuff after first customizing or patching the software

In all cases, you need to gather the software together and decide whether you want everything to go into one bundle or a number of bundles.

As covered in Chapter 1, Introduction to RPM , a major tenet of the philosophy behind RPM is to start with pristine—unmodified--sources. You may need to patch or customize the sources for your environment, but you can always go back to the original sources.

Starting with pristine sources provides a number of advantages, including the following:

*You clearly separate any changes you have made to the software from the original software.

*You make it easier to get an upgrade of the original sources, since your changes are cleanly separated from the original sources. With each new release of the software, you can determine which of your changes, if any, are still needed. This is especially important if you are packaging an application created by another organization into an RPM.

*You have a reproducible way to recreate everything in the package. Since you start with unmodified sources, you can always go back to the beginning of the process and start again. Thus, your RPMs don’t depend on any actions taken beforehand, such as patching, that you may later forget to do because the steps are not automated as part of the RPM-building process.

Start with pristine sources; then patch as needed. A patch is an automated set of modifications to the source code. Use the diff command to build a patch and the patch command to apply the patch (that is, to modify the source code). Keep the original sources separate from any patches you need to make the software work in your environment.

Cross Reference

See the online manual pages for the patch and diff commands for more information on how to create and apply a patch.

The RPM system will automate the steps to create an application, as long as you configure the RPM with the proper steps, such as which make targets to run. Unfortunately, configuring the proper steps is not always easy. So before trying to make an RPM, you need to figure out how to build the application or library you plan to package into an RPM. Once you have figured out how to build the application or library, you can set up a reproducible build. The RPM system can then automate this build.

To build the software, you’ll need to use a variety of Linux tools. The specific tools you need depend largely on where the original software came from. The following sections outline some of the more common techniques for preparing and building Linux software.

Any application or library you package in RPM format is likely to get upgraded sometime. When this happens, you’ll need to make a new RPM. This new RPM must handle not only installing the package, but also handling any upgrade issues. You need to think about the following issues:

*How to install the RPM for the new version of the software. Are there any necessary install scripts?

*How to remove the previous RPM package. If your package has an install script, then you may need an uninstall script to cleanly remove any changes made to the system by the install script. The RPM system handles the removal of the files in the package. You need to handle the task of undoing any changes made to the system during installation.

At this point in time, the main effort is to keep these issues in mind and plan ahead, since these issues will come up with any upgrade.

Often, the hardest task is getting make to build a program properly. One potential problem is assuring that all the dependencies are included. As you work with make, keep track of any other libraries that the program you are trying to build requires. These libraries will become dependencies when you get to the stage of making the RPM.

In most cases you do not want to include the dependencies in your RPM. Instead, each dependency should have its own RPM for each necessary library. In many cases, you should be able to find RPMs for these dependencies. Keep track of the packages that provide the dependencies.

After you have built the application, planned for upgrades and outlined dependencies, you can make an RPM.

The RPM system expects five directories, as listed in Table 9-1.

Table 9-1 RPM directories

The RPMS directory usually has a number of architecture-specific subdirectories, such as the following (on an Intel architecture system):

$ ls RPMS

athlon

i386

i486

i586

i686

noarch

By default, Red Hat Linux systems expect RPMs to be built in the /usr/src/redhat directory.

Note

This directory is obviously specific to Red Hat Linux. On other Linux distributions, you'll likely see other directories.

Within the /usr/src/redhat directory, you’ll see the subdirectories listed in Table 9-1, as follows:

$ ls /usr/src/redhat

BUILD

RPMS

SOURCES

SPECS

SRPMS

At first, it seems rather odd to be using a system directory to build RPMs. But remember that the RPM system was originally built to create Linux distributions. You can also change the default directories by modifying your rpmrc settings.

Cross Reference

See Chapter 20, Customizing RPM Behavior for more on the use of the rpmrc settings.

For now, it is easiest to just change to the /usr/src/redhat directory and work from this location. To start, you will need to change ownership or permissions on these files so you can build RPMs while logged in as a normal user.

Warning

Do not build RPMs while logged in as root. Mistakes in building packages can have serious consequences if you are logged in as root.

To build RPMs, you really need only two things:

*Your sources in the SOURCES directory

*Your spec file in the SPECS directory

You can place all the source files directly in the /usr/src/redhat/SOURCES directory. In most cases, however, it is easier to create a tarball of the sources you want to build and place the tarball file in the /usr/src/redhat/SOURCES directory. The RPM specifications for commands necessary to extract the sources from such a file are trivial. Furthermore, the tarball, when extracted, should create a subdirectory specific to your package. This keeps your source code separate from other packages that also have source code in the SOURCES directory.

The best strategy is to start in a directory of your own making, create the tarball file from the sources, and then copy the tarball file to the /usr/src/redhat/SOURCES directory.

The convention for these tarball files is package-version.tar.gz. For example:

jikes-1.17.tar.gz

Place a file like this into the /usr/src/redhat/SOURCES directory. This file should include all the sources, all the build scripts, and any documentation you want to install as part of the package.

The spec file, short for specification file, defines all the actions the rpmbuild command should take to build your application, as well as all the actions necessary for the rpm command to install and remove the application. Each source RPM should have the necessary spec file for building a binary RPM.

The spec file is a text file. The normal naming convention is to name the file with the package name and a .spec filename extension. For example, the jikes package spec file would be named jikes.spec.

Inside the spec file, format the information on the package using a special syntax. This syntax defines how to build the package, version numbers, dependency information, and everything else you can query about a package. This syntax differs slightly depending on the sections in the spec file. The following sections describe these spec file sections and the necessary syntax in each section.

To build RPMs with the rpmbuild command, use the following basic syntax:

rpmbuild -bBuildStage spec_file

The -b option tells rpmbuild to build an RPM. The extra BuildStage option is a special code that tells the rpmbuild command how far to go when building. Table 9-2 lists these options:

Table 9-2 Options for building with rpmbuild

Note

See chapter 12 for advanced options you can use with rpmbuild.

For example, to set up all the necessary files and prepare for building, run the following command:

rpmbuild –bp specfile

This example runs through the %prep section, and stops immediately after this section. With the jikes package, for example, you’ll see a result like the following:

$ rpmbuild -bp /usr/src/redhat/SPECS/jikes.spec

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.72435

+ umask 022

+ cd /usr/src/redhat/BUILD

+ LANG=C

+ export LANG

+ cd /usr/src/redhat/BUILD

+ rm -rf jikes-1.17

+ /usr/bin/gzip -dc /usr/src/redhat/SOURCES/jikes-1.17.tar.gz

+ tar -xf -

+ STATUS=0

+ '[' 0 -ne 0 ']'

+ cd jikes-1.17

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

++ /usr/bin/id -u

+ '[' 500 = 0 ']'

+ /bin/chmod -Rf a+rX,g-w,o-w .

+ exit 0

After running this command, the source files are extracted into the /usr/src/redhat/BUILD directory, under the jikes-1.17 subdirectory. Using a subdirectory keeps the sources for this package from intermixing with the sources for other packages.

Running a directory listing on the /usr/src/redhat/BUILD/jikes-1.17 subdirectory shows what the spec file %prep section commands have done. For example:

$ ls -1 /usr/src/redhat/BUILD/jikes-1.17

acinclude.m4

aclocal.m4

AUTHORS

ChangeLog

config.guess

config.sub

configure

configure.in

COPYING

depcomp

doc

INSTALL

install-sh

jikes.spec

Makefile.am

Makefile.in

missing

mkinstalldirs

NEWS

README

src

TODO

Note

From these sources, you see a configure script. The configure script gives a good indication of how the software needs to be built. This example also shows a README file. You know what to do with these files.

The actual source code is in the /usr/src/redhat/BUILD/jikes-1.17/src directory. The user documentation is stored in the /usr/src/redhat/BUILD/jikes-1.17/doc directory.

To build a binary RPM, use the –bb option to the rpmbuild command. For example:

$ rpmbuild -bb /usr/src/redhat/SPECS/jikes.spec

Warning

Don’t build packages when you are logged in as the root user. Log in as a normal user instead. This is to limit the damage caused to your system if the spec file or the Makefile contains errors that delete system files, for example. If you are logged in as the root user, you will have permission to perform these destructive acts. If you are logged in as a normal user, though, these RPM spec file and Makefile errors will fail to run, because you don’t have permission to modify system files.

This command results in a lot of output, most coming from the configure script. (This script examines the C programming environment on your system.) When the rpmbuild command completes, you’ll see the binary RPM in the proper subdirectory of the RPMS directory. You can see the RPM with a directory listing, for example:

$ls /usr/src/redhat/RPMS/i386:

jikes-1.17-1.i386.rpm

To stop execution just after the %install section, use a command like the following:

rpmbuild –bi specfile

For example:

# rpmbuild -bi /usr/src/redhat/SPECS/jikes.spec

To build a source RPM out of the files you have (in this case a tar archive of the sources and the spec file), use a command like the following:

rpmbuild –bs specfile

For example:

$ rpmbuild -bs /usr/src/redhat/SPECS/jikes.spec

When done, you’ll see the source RPM in the /usr/src/redhat/SRPMS directory:

$ ls /usr/src/redhat/SRPMS

jikes-1.17-1.src.rpm

To clean out the files created by building these RPMs, use the --clean option to the rpmbuild command:

rpmbuild --clean specfile

For example: