Once again, there's not very much output. This is because the test succeeded; had there been a problem, the output would have been a bit more interesting. In this example, there are some problems:

# rpm -i --test rpm-2.0.11-1.i386.rpm

/bin/rpm conflicts with file from rpm-2.3-1

/usr/bin/gendiff conflicts with file from rpm-2.3-1

/usr/bin/rpm2cpio conflicts with file from rpm-2.3-1

/usr/bin/rpmconvert conflicts with file from rpm-2.3-1

/usr/man/man8/rpm.8 conflicts with file from rpm-2.3-1

error: rpm-2.0.11-1.i386.rpm cannot be installed

#

Note the version numbers. We're trying to install an older version of RPM (2.0.11) on top of a newer version (2.3). RPM faithfully reported the various file conflicts and summarized with a message saying that the install would not have proceeded, even if --test had not been on the command line.

The --test option will also catch dependency-related problems:

# rpm -i --test blather-7.9-1.i386.rpm

failed dependencies:

bother >= 3.1 is needed by blather-7.9-1

#

2.4.3. --replacepkgs: Install the Package Even if It's Already Installed

The --replacepkgs option is used to force RPM to install a package that it believes to be installed already. This option is normally used if the installed package has been damaged somehow and needs to be fixed up.

To see how the --replacepkgs option works, let's first install some software:

# rpm -iv cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

#

Okay, now that we have cdp-0.33-2 installed, let's see what happens if we try to install the same version on top of itself:

# rpm -iv cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

package cdp-0.33-2 is already installed

error: cdp-0.33-2.i386.rpm cannot be installed

#

That didn't go very well. Let's see what adding --replacepkgs will do:

# rpm -iv --replacepkgs cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

#

Much better. The original package was replaced by a new copy of itself.

2.4.4. --replacefiles: Install the Package Even if It Replaces Another Package's Files

While the --replacepkgs option permits a package to be installed on top of itself, --replacefiles is used to allow a package to overwrite files belonging to a different package. Sounds strange? Let's go over it in a bit more detail.

One thing that sets RPM apart from many other package managers is that it keeps track of all the files it installs in a database. Each file's database entry contains a variety of information about the file, including a means of summarizing the file's contents. By using these summaries, known as MD5 checksums, RPM can determine whether a particular file is going to be replaced by a file with the same name but different contents. The following paragraphs give an example.

Package A installs a file (we'll call it /bin/foo.bar). When Package A is installed, foo.bar resides happily in the /bin directory. In the RPM database, there is an entry for /bin/foo.bar, including the file's MD5 checksum.

However, there is another package, B. Package B also has a file called foo.bar that it wants to install in /bin. There can't be two files in the same directory with the same name. The files are different; their MD5 checksums do not match. What happens if Package B is installed? Let's find out. Here, we've installed a package:

# rpm -iv cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

#

Okay, no problem there. But we have another package to install. In this case, it is a new release of the cdp package. Note that RPM's detection of file conflicts does not depend on the two packages being related. It is strictly based on the name of the file, the directory in which it resides, and the file's MD5 checksum. Here's what happens when we try to install the package:

# rpm -iv cdp-0.33-3.i386.rpm

Installing cdp-0.33-3.i386.rpm

/usr/bin/cdp conflicts with file from cdp-0.33-2

error: cdp-0.33-3.i386.rpm cannot be installed

#

What's happening? The package cdp-0.33-2 has a file, /usr/bin/cdp, that it installed. Sure enough, there it is. Let's note the size and creation date of the file for future reference:

# ls -al /usr/bin/cdp

-rwxr-xr-x 1 root root 34460 Feb 25 14:27 /usr/bin/cdp

#

The package we just tried to install, cdp-0.33-3 (note the different release), also installs a file cdp in /usr/bin. Since there is a conflict, the two packages' cdp files must be different—their checksums don't match. Because of this, RPM won't let the second package install. But
with--replacefiles, we can force RPM to let /usr/bin/cdp from cdp-0.33-3 replace /usr/bin/cdp from cdp-0.33-2:

# rpm -iv --replacefiles cdp-0.33-3.i386.rpm

Installing cdp-0.33-3.i386.rpm

#

Taking a closer look at the copy of /usr/bin/cdp that was just installed, we find that they certainly are different, both in size and creation date:

# ls -al /usr/bin/cdp

-rwxr-xr-x 1 root root 34444 Apr 24 22:37 /usr/bin/cdp

#

File conflicts should be relatively rare occurrences. They happen only when two packages attempt to install files with the same name but different contents. There are two possible reasons for this to happen:

• Installing a newer version of a package without erasing the older version. A newer version of a package is a wonderful source of file conflicts against older versions—the filenames remain the same, but the contents change. We used it in our example because it's an easy way to show what happens when there are file conflicts. However, it is usually a bad idea to do this as a way to upgrade packages. RPM has a special option for this (rpm -U) that is discussed in Chapter 4.
• Installing two unrelated packages that each install a file with the same name. This may happen because of poor package design (hence the file's residing in more than one package) or a lack of coordination between the people building the packages.

What happens if a conflicting file is a config file that you've sweated over and worked on until it's just right? Will issuing a --replacefiles on a package with a conflicting config file blow all your changes away?