Chapter 04

Using RPM

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

In This Chapter

*	Installing and upgrading software

*	Removing software

This chapter covers the most common uses for RPM: installing, removing, and upgrading software. These are the most frequently used RPM commands.

The RPM system includes the options you might expect, such as installing a package, but there’s a lot more you can do. For example, you can install packages from remote sites using HTTP or FTP to download the package to install. There are quite a few other rpm options you can use to get information and feedback on installation, for example.

The rpm Command

Just about everything you do with RPM requires the rpm command. As a nice added benefit, just about everything you do with RPM requires a single invocation of the rpm command. That means common tasks such as installing and removing software can be done quickly and efficiently. The basics of the rpm command are not very hard, and you can perform the basic tasks within a few minutes of reading this chapter.

Upgrading and Installing Software

To install software, you need something to install. Typically, this is a file packaged as RPM, using a file-name extension of .rpm. Of course, this isn’t required, but just about every RPM package is stored in a file with a .rpm extension. For example, the following file holds an RPM package, ready to be installed:

jikes-1.16-1.i386.rpm

This package holds an application named jikes (a Java language compiler application). From the discussion in the last two chapters, you should be able to determine the version of the program this RPM holds and which release of the RPM package this represents.

Other RPMs hold sources, the program source codes used to create an application or programming library. For example, the following file holds a source RPM:

jikes-1.16-1.src.rpm

The src in the package name is short for source. This file-naming convention is not required, but is used by just about all source code packages. (Following conventions helps other administrators know what to expect.)

Cross Reference

Chapters 9 and 12 cover building RPMs from source RPMs.

The rpm command provides three main operations for upgrading and installing packages:

An upgrade operation means installing a new version of a package and removing all previous versions of the same package. If you have not installed a package previously, the upgrade operation will install the package.

A freshen operation means to install a new version of a package only if you have already installed another version of the package.

An install operation installs a package for the first time. It also, through special command-line parameters, allows you to install multiple versions of a package, usually not what you want. So, in the vast majority of cases, you want to run the upgrade operation for all package installations.

The following sections cover the command-line options that apply to these operations.

Upgrading with the rpm command

Almost all installation steps use the rpm command with the –U option, short for upgrade, as introduced in Chapter 3. 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 12 covers signing packages. In most cases, warnings such as this one are not that serious. Errors, though, should be treated seriously.

Note

Just about every package you want to upgrade or install requires root, or super user, permissions. That’s because most Linux application RPMs hold files that must be installed in a protected directory such as /usr/bin. In addition, RPM requires root access to modify the RPM database. Even if you could modify the system directories like /usr/bin, you must also be able to modify the RPM database to successfully install or remove packages.

Checking That the Package Is Installed

Use the rpm –q command to quickly verify a package has been installed. To verify, you need to use the name of the installed package, not the name of the RPM file. You can also use a partial package name, such as jikes in this case. For example:

rpm –q jikes

When you run this command, you should see a response like the following:

jikes-1.16-1

The response shows that the package named jikes-1.16-1 has been installed. This package name corresponds to the RPM file used in the preceding installation example.

The rpm -q command just asks the RPM database if the package has been installed. There may be other issues with the package that this command won’t show. For now, though, the rpm –q command verifies that package has been installed.

If the package has been not installed, you will see a message similar to the following:

package jikes is not installed

Getting Feedback During Installation and upgrades

The -h option to the rpm command prints out # signs, also called hash marks (hence the -h). These hash marks provide some confirmation that the rpm command is still running. This is important, since large packages may take a long time to install or upgrade. Run this command like the following:

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

You'll see this output:

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

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

The hash marks are printed one at a time as the command does its work. If the package was not created properly, you may see warnings like the following:

########################################### [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%]

Note

You can install a package more than once. The rpm command won't complain. The upgrade operation, though, will remove all other versions of a package. This is one more reason to use the –U upgrade option.

In addition to hash marks, you can get more verbose output from the tight-lipped rpm command. The -v option to the rpm command tells the command to print out verbose information as the command runs. Remember, though, that verbose is used in the traditional Unix and Linux meaning, which is normally not all that verbose. In the Unix/Linux context, verbose usually means slightly more than nothing. The syntax for the command follows:

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

With the -v command-line option, you will see output more like the following:

Preparing... ########################################### [100%]

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

Note

The most common command to install a package is

rpm -Uhv package_file.rpm

That is, upgrade with verbose output and hashes.

To get extra verbose information, use the -vv command-line option. Think of this as doubly verbose. Usually, though, this extra information has no meaning unless you are debugging an RPM package you are building. See the chapters in Part II on Creating RPMs for more on how to build RPM packages.

A double-verbose command uses much the same syntax as shown previously:

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

With the double-verbose option, the output appears as follows:

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 elments

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

Note

Although most Unix and Linux applications use a single minus sign for command-line options, such as rpm -U, many programs use two minus signs to indicate longer option names. For example, with the rpm command, -U and --upgrade are treated the same. You can use the short option, -U, or the long option, --upgrade.

There are long options for virtually every short option. There are also long options that are rarely used, for which there are no short options.

One rarely used feedback option is --percent. The --percent option prints out decimal numbers that show the percentage completed as the rpm command executes. This option is most useful if you wrap the rpm command within some other command, such as a graphical user interface created from a Perl, Python, or Tcl/Tk script.

The basic syntax is:

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

When you run this command, you see output like the following:

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

These decimal numbers output by the --percent option are really meant to be input into another program, perhaps a program that shows a graphical progress meter. Each number output then updates the meter.

Note

Don't trust the numbers too much. Claiming the package is 53.139442 percent installed just asks the user to be skeptical that it is exactly that far.

The Installation Task In Detail

You can use the rpm –U command or the rpm –i command to install a package. When the rpm command installs a package, it goes through a number of steps:

*	Checking the package and the files it wants to install

*	Performing preinstallation tasks

*	Uncompressing the files and placing them in the proper locations

*	Performing post-processing tasks

*	Updating the RPM Database

When checking the package, rpm checks that all the dependencies are installed. Dependencies are packages required by the RPM package you want to install. For example, a database-administration package for a particular database may require that the database itself was already installed.

In addition to checking for dependencies, the rpm command checks for conflicting packages. For example, when you are trying to install an older version of a package on top of a newer version, running the rpm command alerts you to that conflict. This conflict-checking goes deeper than packages, though. Individual files may conflict if you are trying to install a package that has an older version of a particular file.

After the checks, the rpm command executes the preinstallation tasks (covered in depth in Part II). After all this preparatory work, the rpm command finally gets down to business and installs the files in the package. These files are stored in compressed format (compressed with gzip compression) inside the RPM file.

After installing the files, there may be some post-processing tasks (also covered in Part II). At the end of its run, the rpm command updates the RPM database to reflect the new package information. This update is very important and allows you to track packages.

Taking a Test Drive

The --test command-line option tells the rpm command to test the installation or upgrade process but not to install the file. For example, the following command performs an upgrade or install of the jikes package, but in test mode only. No files will actually be installed.

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

This command will print nothing if the tested installation or upgrade runs smoothly. If, on the other hand, a problem results from the tested installation, you will receive an error message. If the package is already installed, you will see a message like the following:

package jikes-1.16-1 is already installed

If the file is corrupted, you will see output like the following:

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

This example was run against a file that was clearly not an RPM package.

The test option can help you determine package dependencies, too.

You can often determine dependencies at a glance--if you know something about the software you are installing. For example, if you know that Ruby is a scripting language, you can guess that packages starting with eruby, such as eruby-devel-0.9.8-2.i386.rpm, will depend on a base ruby package.

To show this, query for any ruby packages by using a command like the following:

rpm -q ruby

If you have not installed a ruby package, you'll see a message like the following:

package ruby is not installed

Note

Most packages use all lowercase names. Thus, you can expect packages for the Ruby scripting language to start with ruby.

Package dependencies can quickly devolve into a nightmare in which one package depends upon another and that package in turn depends on yet another.

This is where the --test option comes in handy, since you can check that the dependencies are resolved prior to trying to install. (Note that the rpm command will check dependencies on real installs as well. The --test option just allows you to check that the installation will succeed prior to trying it.) For example, if you try to install a package named eruby-devel-0.9.8-2.i386.rpm, you may want to run a --test option first:

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

You'll then see a response like the following, presuming you have no ruby packages installed:

error: Failed dependencies:

eruby-libs = 0.9.8 is needed by eruby-devel-0.9.8-2

Now you can see that the package in the file eruby-devel-0.9.8-2.i386.rpm depends on another package, eruby-libs in this case. In fact, this package depends on the eruby-libs package having a version number of 0.9.8. These packages are obviously interrelated. From the name eruby-libs, you can guess that the package will be in a file with a name like eruby-libs-0.9.8-2.i386.rpm. (I cheated and used the actual package on the Red Hat installation CDs.)

But you can see how the version numbers of the two files, and the RPM revision levels, match up, as follows:

eruby-devel-0.9.8-2.i386.rpm

eruby-libs-0.9.8-2.i386.rpm

So, now you think your problems are over. You have the package that eruby-devel-0.9.8-2.i386.rpm depends on: eruby-libs-0.9.8-2.i386.rpm. Just to be careful, though, you can test that package as well, with a command like the following:

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

Alas, this output leads you farther down into dependency nightmare:

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

This short example shows why it makes sense to test packages prior to installing or upgrading them.

Installing or upgrading More Than One Package At A Time

Up to now, all the examples shown have used the rpm command to install or upgrade one package at a time. You can optionally choose to install or upgrade a number of packages at the same time. Just list each file name on the rpm command line. The basic syntax follows:

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

Simply list all the packages one after another. For example:

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

This command installs two packages, the aspell packages for Canadian and British English, respectively.

The --noorder option tells the rpm command not to reorder the packages you are trying to install. Usually, the rpm command will reorder the list of packages in the best order for handling the dependencies. This option really only comes into play when you are installing more than one package where the packages depend on each other. In most cases, you do not want to use this option, since this may mean that packages fail to properly install because necessary packages are not already installed.

Installing in Different Directories

The --prefix and --relocate options should make the rpm command relocate a package to a new location. Not all packages allow relocations, though. The basic format of the command with the --prefix option is:

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

With the --relocate option, the command format is:

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

You can also use the --root option to specify a different directory for the rpm command to assume is the system's root, or /, directory. This causes the rpm command to install files under the new root, instead of in system locations under /. This option is most useful for testing the installation of a complete system under a test directory. The command should use the following format:

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

The --root option tells the rpm command that the root for this install is in /tmp. Installs with the --root option take place within a chroot() environment. This is often useful for setting up a test environment.

The --dbpath option tells the rpm command that the RPM database is located in the normal location, /var/lib/rpm.

Using the --dbpath and --root options will give you problems unless you have installed all the dependencies in the same virtual root directory. This includes all the standard Linux C libraries. For example, if you just run the example command, you'll see error output like the following:

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

You can use the --badreloc option with the --relocate option to permit relocations on all files in the package. Usually, only those paths to files that are listed as relocatable are supported by the --relocate option.

Forcing the Issue

A number of rpm options cause the rpm command to complain about problems and, in general, fail to install your package. You can use a number of options to run roughshod over the RPM and get it to do what you want.

The --replacepkgs option tells the rpm command to replace, or reinstall, packages it may have already installed.

The --replacefiles option tells the rpm command to overwrite files owned by a another package.

The --justdb option tells the rpm command to update the RPM database, not to install the files. You will need to be logged in as the root user to modify the RPM database.

The --nosuggest option tells the rpm command to skip any suggestions for packages that may fill in missing dependencies. You almost never want to use this option.

The --excludepath option tells the rpm command to exclude all files that start with the given path. For example:

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

This command installs or upgrades all the files in the package, except for those files that would be placed in a directory starting with /usr/lib.

The --allfiles option tells the rpm command to install or upgrade all files in the package, regardless of whether the files exist or not on your hard disk.

The --oldpackage tells the rpm command to allow you to install an older version of a package on top of a more recent one. You don't usually want to do this, but you may need to under the following circumstances:

*	If the more recent package has some bug or security vulnerability and you need to downgrade to a former version.

*	If the more recent package won't work with some other package that depends on a particular former version of a package.

The latter case is very common if you upgrade your system in a piecemeal fashion. If a low-level library changes, it may take a while for all the packages that depend on the low-level library to get updated to use the latest version.

Note that when you purchase an upgraded version of Linux, such as Red Hat Linux, all the packages with the product should be properly aligned with each other as to versions. This alignment problem is an issue that the Linux vendors, such as Red Hat, need to take care of. The main problems occur when you need packages beyond those offered with your Linux distribution.

To combine some of these options, you can use --force, which tells the rpm command to turn on the --replacepkgs, --replacefiles, and --oldpackage modes.

The --nodeps command-line option tells the rpm command to skip the dependencies check and install anyway.

Warning

The rpm command complains with good reason. Unless you really, really know what you are doing, don't force the issue by using these command-line options.

Consider the eruby-devel-0.9.8-2.i386.rpm from the previous example. You can force the rpm command to install this package, even though it depends on another package that in turn depends on yet another. The following command will force the installation of the package in the eruby-devel-0.9.8-2.i386.rpm file:

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

Just to be sure, you can query for the package using a command like the following.

rpm -q eruby-devel

The response should be:

eruby-devel-0.9.8-2

The package is installed, but it likely won't work, since it really does depend on other packages. These package dependencies aren’t for show. You may have a valid reason to force a package to get installed, but you should go back later to try to resolve all the dependencies.

In addition to forcing the rpm command not to do certain things, you can use the --aid option to have the rpm command do something nice for you. The --aid option tells the rpm command to add all the packages it would suggest into the set of packages to install. The rpm command has enough information to suggest a package or packages that ought to contain the dependent files.

The --aid option depends on a separate package that contains an RPM database with all packages installed. For Red Hat Linux, this package is rpmdb-redhat. This separate database, built as if all packages were installed (all packages that come with Red Hat Linux in this case), allows the rpm command to search for which packages would solve dependencies.

Skipping the Scripts

As part of the package installation, as well as removal, the RPM package may have scripts that the rpm command should run. These include pre- and post-installation scripts, as well as pre- and post-uninstallation scripts. These scripts can perform options such as automatically configuring the application based on the target environment. For example, an installation script may try to detect whether a site uses postfix or sendmail for transferring mail messages and configure the newly-installed package accordingly.

In most cases, the rpm command will execute these scripts at the proper time, unless you explicitly turn the command to skip the scripts. The --noscripts option tells the rpm command to skip running the pre- and post-installation scripts.

If you want, you can exercise a finer grain of control. The --nopre option tells the rpm command to skip any pre-installation scripts. The --nopost option tells the rpm command to skip any post-installation scripts.

Similarly, the --nopreun option tells the rpm command to skip any pre-uninstallation scripts, and the --nopostun option tells the rpm command to skip any post-uninstallation scripts.

The --noscripts option is the same as turning on all these options.

Table 4-1 summarizes these options.

Table 4-1 Skipping scripts

Option	Usage
--nopre	Skip pre-installation scripts.
--nopost	Skip post-installation scripts.
--nopreun	Skip pre-uninstallation scripts.
--nopostun	Skip post-uninstallation scripts.
--noscripts	Skip all the scripts; same as --nopre, --nopost, --nopreun, and --nopostun.

In most cases, you never want to disable these scripts. Many RPMs uses these scripts to perform the final steps of the installation, especially the post-installation scripts. For example, the Mozilla Web browser and most network services require some kind of post-processing (using a post-installation script) or the packages will not be properly installed.

In addition to pre- and post-installation scripts, the RPM system supports triggers, a topic covered in detail in Chapter 11.

During installation, you can tell the rpm command not to execute all the triggers or not to execute certain triggers. The --notriggers option tells the rpm command to skip all triggers.

You can gain more fine-grained control with a further set of options in place of --notriggers. The --notriggerin option turns off triggers during installation. The --notriggerun option turns off uninstallation triggers, and the --notriggerpostun option turns off the post-uninstallation triggers.

The --notriggers option is the same as all three, --notriggerin, --notriggerun, and --notriggerpostun.

Table 4-2 summarizes these options.

Table 4-2 Skipping Triggers

Option	Usage
--notriggerin	Skip installation triggers.
--notriggerun	Skip uninstallation triggers.
--notriggerpostun	Skip post-uninstallation triggers.
--notriggers	Skip all the triggers; same as --notriggerin, -- notriggerun, and -- notriggerpostun.

Ignorance Is Bliss

The rpm command supports several ignore options that tell the command to ignore some aspect of a package it would normally complain about.

The --ignorearch option tells the rpm command to ignore the architecture of the package and install the package, even if the architecture of the package and the architecture of your system do not match. This is a very dangerous option. Linux runs on everything from tiny wristwatches, PDAs such as the Sharp Zaurus, PCs, Macintosh PCs, RISC servers, and all the way up to huge supercomputers and mainframes. If you try to install a binary package compiled for the ARM or PowerPC processor on an Intel-architecture Linux system, the package will at best fail. At worst, it may damage parts of your system.

Similarly, the --ignoreos command-line option tells the rpm command to ignore the operating system. Again, this is likely not a good idea in most situations. Applications compiled for Windows generally won’t run on Linux. SCO Unix systems, however, can run some Linux applications, so you may have a valid reason to ignore the operating system. Again, use only with extreme care.

The --ignoresize option tells the rpm command to ignore or skip a check of your hard disk to ensure it has enough space to install the package.

Warning

Don't use the --ignoresize option if you have a nearly full hard disk, especially for a root, or /, partition.

The --nodigest option tells the rpm command to skip the test of the digest, the special value that helps verify the package correctness.

The --nosignature option tells the rpm command to skip the test of the digest, the encrypted key, that helps also verify the package correctness.

Warning

Use these rpm command-line options with extreme care and only after carefully considering the circumstances. Wrongful use of these options may damage your operating system.

Documentation? What Documentation?

The --excludedocs command-line option tells the rpm command to ignore any files in the RPM package that are marked as documentation. Considering the general lack of documentation for many Linux applications, you are really asking for trouble by invoking this option. If the documentation takes up a lot of disk space, however, you may want to avoid installing documentation files. This is about the only situation in which this option makes sense.

In reverse of --excludedocs, the --includedocs command-line parameter tells the rpm command to install documentation. This is usually the default, so you rarely need this option.

Upgrading packages

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.

Options When Upgrading

You can pass more than one package name on the command line when upgrading. In addition, you can use the installation and upgrade options discussed previously when upgrading.

Note

When upgrading, the --noscripts option only turns off the scripts from the new package. If an old package is removed, the uninstallation scripts for the old package still get executed.

When upgrading, you can also use the --repackage option, which works the same as when removing packages. The --repackage option tells the rpm command to create a package, an RPM file, from any packages it would erase. Note that this option will not create a complete package. You will not be able to reinstall a package created by the --repackage option. At best, the --repackage option provides a backup of the old package, from which you could create a working package. Be careful with the --repackage option.

For example, the following command shows how to upgrade a package with the --repackage option.

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

Note

Upgrading and freshening depend on versions of a particular package keeping the same base package name between versions. For most packages this is true, but some packages violate this convention. For example, the Java programming developer's kit (JDK) uses the name jdk-1.3.1_01.i386.rpm for the 1.3.1 version but changes to j2sdk-1_4_0_01-fcs-linux-i386.rpm for the 1.4.0 version.

Watch out for package-name changes like this.

Smart Upgrades

The rpm command really shines in the upgrade process. Not only can you upgrade a package with one simple command, but the rpm command has some built-in smarts that really help.

When upgrading, the rpm command checks each file in the package. It actually compares checksums of the files. An MD5 checksum is a small value computed from the data in a file. Any change to a file results in a different checksum value.

The rpm command compares the checksums of three versions of each file: the version of the file from the old package, the version of the file in the new package, and the version of the file on disk.

The rpm command looks at all three versions of the files to handle the common case where you may have edited a configuration file on disk. This is where the rpm command starts working with some upgrade rules. Note that this special processing only applies to files marked as configuration files within the RPM. Chapter 10 covers how to mark files as configuration files.

If the file on disk is identical to the file in the original package, meaning you have not changed the file, the rpm command simply installs the file from the new version of the package on top of the old file.

If the original package configuration file and the new package file are the same, that is, the file has not changed between the package versions, but the configuration file has been changed on disk, the rpm command leaves that file alone. The rpm command makes the assumption that if the file hasn’t changed between versions of the package, and you have modified the file, chances are your file will work with the new package. This takes care of the common case where you have edited an application’s configuration files.

But if the file on disk is different from the original version of the file, and the file on disk is different from the new version of the file, the rpm command installs the new version of the file on top of your changed version. This is because the new version of the file is known to work with the new package. The rpm command saves your work by backing up your modified configuration file, renaming the file with a new .rpmsave extension. The rpm command also warns you that it is backing up your modified file with a message that tells you the old file name and the new file name.

If the RPM package uses the option %config(noreplace) with the file, then the rpm command will store the new file with a .rpmnew extension if you have modified the file on disk.

Freshening up

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.

Installing Packages

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

Warning

You should normally install packages with rpm -U, not rpm -i. One of the main reasons is that rpm -i allows you to install multiple instances of the same (identical) package. This is usually not what you want.

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.

Installing Over the Internet

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.

Warning

When using either FTP or HTTP, you need to provide the name of the remote server. An attack on your system can compromise the system of converting server host names into network addresses, thus spoofing the rpm command into installing a malicious package from the wrong host.

Installing Using FTP

The key to making the network protocols work with the rpm command is that you need to create a URL for the remote file name. The basic format of the command follows:

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

Note the use of ftp: in the URL for the file.

For example, the following downloads a package from an IBM FTP server.

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

Many FTP servers require users to log in. If you do not pass a user name and password on the rpm command line, the rpm command will prompt you for the missing data.

You can add a user name prior to the host name, separating the user name from the host name with an at sign, @. For example:

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

In this case, the user name is unclejoe.

Note

These examples do not show valid user names or passwords.

With just a user name, the rpm command will prompt you for the password. You can also include the password on the rpm command line. Separate the user name from the password with a colon (:).

For example:

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

In this case, the user name is unclejoe and the password is workers.

Installing Using HTTP

The rpm command supports the HTTP protocol, used by most Web servers, as well as FTP. Similar to accessing a file via FTP, you need to pass the rpm command a URL identifying the file. For example:

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

Installing source RPMs

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.

Note

A patch is a file that contains just the differences between one version of a file and another. The differences include the actual text that has changed and enough contextual information that a program can locate where the changes are to take place. Usually, a patch is created with the diff command, and the source code is patched with the patch command.

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 10 for more on the source files and options for not including the sources in a source RPM.

Open-source Software

Linux and thousands of applications that run on Linux are called open-source software. That’s because the program source code for Linux and many applications are available.

Many users feel having access to the source code is vital, especially because:

*	Vendors may stop supporting a package. With the sources, you can—conceivably--maintain the packages yourself, or more likely, others can take up the task and maintain these crucial packages.

*	Having the source code makes it easier to track down and fix security vulnerabilities, although malicious users also have access to the same source code.

*	You can enhance and extend packages for which the program sources are available.

Linux applications are available under a variety of open-source licenses. (In fact, it may seem that there are as many licenses as packages.) See the site www.opensource.org/licenses/ for details.

Removing Software

The rpm command is good for more than just installing and upgrading software packages. Many times, you will need to remove packages as well.

To remove a package, use the -e option to the rpm command, short for erase. The basic syntax follows:

rpm -e package_name

Note

When erasing or removing packages, use the package name, not the RPM file name. If you think about this, it makes sense. You don't always have the original RPM files when the time comes to remove a package.

For example:

rpm -e jikes-1.16-1

This example removes the jikes-1.16-1 package used in previous examples.

Note

You will need to be logged in as the root user, or super user, to remove most packages. This is because the package files themselves are protected. In addition, the RPM database is protected.

This is only natural, since most RPMs are used to install system-level commands and applications.

When removing a package, the rpm command first checks that no other packages depend on the package you intend to remove. This is very important, since you otherwise can damage your Linux system by inadvertently removing packages needed by the rest of the system.

The rpm command supports the --test option for removing packages as well as when installing. As with installing, the --test option tells the rpm command to test to see whether it can remove the given package but not to force the removal.

For example, if you try to remove the very important-looking syslinux-1.75-3 package, you can use the --test option to see if this works.

For example:

rpm -e --test syslinux-1.75-3

This command will issue an error such as the following:

error: Failed dependencies:

syslinux is needed by (installed) mkbootdisk-1.4.8-1

Note

When removing packages, you can use the long option name, --erase, in place of –e.

Checking that the package has been removed

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

Removing multiple packages at a time

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.

Options when removing 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.

Warning

Using any option that does not perform the full removal of the package, or skips some of the checks built into the rpm command, can result in damage to your Linux system. Use these options with care.

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.

Note

Packages created with the --repackage option are not full packages. You cannot install these packages.

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.

Other rpm Command Options

Options such as -v (for more verbose output) work with the rpm command for installing, removing, and upgrading packages, as well as most other uses of the rpm command.

Other rpm command options, which work with most RPM actions, include --quiet to turn off most output except for errors, and --root, covered previously.

The --rcfile option tells the rpm command to use one or more other files to initialize the RPM system. These files tell the rpm command the system architecture, operating system, and default location of the RPM database, among a host of other settings.

Note

The term rc comes from Unix shells, with initialization files such as .cshrc for the C shell, csh. The term rc was originally a shorthand for run commands. An rc is a file of commands that run when the application starts up. For example, the C shell, csh, runs the commands in file named .cshrc when the shell starts.

In most cases, the application looks in the user home directory for a specific file tied to the application. For the rpm command, this file is .rpmrc. The leading period makes the file hidden for most directory listings.

In addition to the user-level file of commands, most applications supporting this mechanism have a way for site administrators to customize the command for all users. For example, your system may have a file named /etc/rpmrc (with no leading period) that customizes the rpm command for all users on your system. See page 427 for a more in-depth look at the chain of these files.

The syntax for the --rcfile option is

--rcfile filename

You can also supply more than one file name. This syntax follows:

--rcfile filename1:filename2:filename3

Separate each file name with a colon.

With Red Hat Linux, the default set of initialization files are:

/usr/lib/rpm/rpmrc:/usr/lib/rpm/redhat/rpmrc:/etc/rpmrc:~/.rpmrc

Note

The ~/.rpmrc means to look in the user's home directory for a file named .rpmrc.

You can use the --showrc option to list all the rc settings.

Cross Reference

See Chapter 21 for more on the --showrc option.

The --version option tells the rpm command to print out the version number of the command and then exit. For example:

rpm --version

This command prints out a version number, like the following:

RPM version 4.1

The --dbpath option, mentioned previously, tells the rpm command to use a different RPM database. This is useful when testing a complete system install, where you want to change the RPM database but don't want that to affect your running Linux system. In this case, you can use a different RPM database and test out your changes. The basic syntax for this option is:

--dbpath directory_name

The --pipe option tells the rpm command to send, or pipe, its output to another program. The syntax for this option is:

--pipe command_to_send_out_to

Summary

This chapter covered the easy part of managing packages, the common actions of installing, removing, and upgrading software.

The rpm –e command removes packages. The rpm –U command upgrades packages by installing new packages and removing old versions of all the packages upgraded. RPM upgrades also work for installing new packages. The rpm –F command freshens packages. This command only upgrades a package if an older version of the package has already been installed. The rpm –i command installs packages.

Table 4-3 summarizes the rpm command-line options for installing, removing, and upgrading packages.

Table 4-3 Installing, Removing, and Upgrading with the rpm command

Command	Usage
rpm –i install_options package_files	Install packages.
rpm –e remove_options packages	Erase, remove, packages.
rpm –U install_options package_files	Upgrade or install packages. Use this option for installations.
rpm –Uvh install_options package_files	Upgrade or install packages with extra output. This is the recommended command to install packages.
rpm –F install_options package_files	Freshen packages.

Unfortunately, modern system management gets more complex than that. The next chapter delves into package dependencies and the nightmare you can get into when one package depends on another that then depends on another, ad infinitum.

Chapter 04

Chris Ricker

2003-01-29T14:09:00

Eric Foster-Johnson