3.2. Upgrading and Installing Software

⁠3.2. 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.)

Building Packages from Source RPMs

Refer to Chapter 8, Creating RPMs: An Overview and Chapter 11, Controlling the Build with rpmbuild for information on building RPMs from source RPMs.

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

Upgrade: 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.
Freshen: A freshen operation means to install a new version of a package only if you have already installed another version of the package.
Install: 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 section cover the command-line options that apply to these operations.

⁠3.2.1. Upgrading with the `rpm` command

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.

root Permissions

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.

⁠3.2.1.1. 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

⁠3.2.1.2. 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%]

Reinstalling Packages

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

Standard Command for Package Installation

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

Short and Long Options

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.

Percentages may be Approximate

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.

⁠3.2.1.3. 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.

⁠3.2.1.4. 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

Package Names

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.

⁠3.2.1.5. 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.

⁠3.2.1.6. 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.

⁠3.2.1.7. 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.

Avoid Forcing Package Operations

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.

⁠3.2.1.8. 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.

The table below summarizes these options.

⁠

Table 3.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 10, Advanced RPM Packaging.

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.

The table below summarizes these options.

⁠

Table 3.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`.

⁠3.2.1.9. 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.

Ignoring Storage Limits

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.

Unsafe Options

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.

⁠3.2.1.10. 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.