At some point the original file was modified and those modifications happen to make the file identical to the new file. Perhaps the modification was made to fix a security problem, and the new version of the file has the same fix applied to it.

In this case, RPM installs the new version, overwriting the modified original. The same philosophy used in the first scenario applies here: Although the file has not changed, perhaps some other aspect of the file has, so the new version is installed.

Here the original file was modified at some point. The new file is different from both the original and the modified versions of the original file.

RPM is not able to analyze the contents of the files and determine what is going on. In this instance, it takes the best possible approach. The new file is known to work properly with the rest of the software in the new package—at least the people building the new package should have ensured that it does. The modified original file is an unknown: It might work with the new package and it might not. So RPM installs the new file.

But the existing file was definitely modified. Someone made an effort to change the file for some reason. Perhaps the information contained in the file is still of use. Therefore, RPM saves the modified file, naming it file.rpmsave, and prints a warning so the user knows what happened:

warning: /etc/skel/.bashrc saved as /etc/skel/.bashrc.rpmsave

While RPM doesn't use checksums in this particular case, we'll describe it in those terms for the sake of consistency. In this instance, RPM had not installed the file originally, so there is no original checksum.

Because the file had not originally been installed as part of a package, there is no way for RPM to determine whether the file currently in place had been modified. Therefore, the checksums for the current file and the new file are irrelevant; they cannot be used to clear up the mystery.

When this happens, RPM renames the file file.rpmorig, prints a warning, and installs the new file. This way, any modifications contained in the original file are saved. The system administrator can review the differences between the original and the newly installed files and determine what action should be taken.

As you can see, in the majority of cases RPM will automatically take the proper course of action when performing an upgrade. It is only when config files have been modified and are to be overwritten that RPM leaves any postupgrade work for the system administrator. Even in those cases, many times the modified files are not worth saving and can be deleted.

4.2. Upgrading a Package

The most basic version of the rpm -U command is simply rpm -U, followed by the name of an .rpm package file:

# rpm -U eject-1.2-2.i386.rpm

#

Here, RPM performed all the steps necessary to upgrade the eject-1.2-2 package, faster than could have been done by hand. As in RPM's install command, uniform resource locators, or URLs, can also be used to specify the package file. (For more information on RPM's use of URLs, see section 2.2.1 in Chapter 2.)

4.2.1. rpm -U's Dirty Little Secret

Well, in the preceding example, we didn't tell the whole story. There was no older version of the eject package installed. Yes, it's true. rpm -U works just fine as a replacement for the normal install command rpm -i.

This is another, more concrete, example of the strength of RPM's method of performing upgrades. Because RPM's install command is smart enough to handle upgrades, RPM's upgrade command is really just another way to specify an install. Some people never even bother to use RPM's install command; they always use rpm -U. Maybe the -U should stand for, "Uh, do the right thing...."

4.3. They're Nearly Identical

Given the fact that rpm -U can be used as a replacement to rpm -i, it follows that most of the options available for rpm -U are identical to those used with rpm -i. Therefore, to keep the duplication to a minimum, we'll discuss only those options that are unique to rpm -U or that behave differently from the same option when used with rpm -i. The table at the beginning of this chapter shows all valid options to RPM's upgrade command and indicates which are identical to those used with rpm -i.

4.3.1. --oldpackage: Upgrade to an Older Version

This option might be used a bit more by people who like to stay on the bleeding edge of new versions of software, but eventually everyone will probably need to use it. Usually, the situation plays out like this:

1. You hear about some new software that sounds pretty nifty, so you download the .rpm file and install it.
2. The software is great! It does everything you ask for and more. You end up using it every day for the next few months.

3. You hear that a new version of your favorite software is available. You waste no time in getting the package. You upgrade the software by using rpm -U. No problem!
4. Fingers arched in anticipation, you launch the new version. Your computer's screen goes blank!

Looks like a bug in the new version. Now what do you do? Hmmm. Maybe you can just "upgrade" to the older version. Let's try to go back to release 2 of cdp-0.33 from release 3:

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

Installing cdp-0.33-2.i386.rpm

package cdp-0.33-3 (which is newer) is already installed

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

#

That didn't work very well. At least it told us just what the problem was: We were trying to upgrade to an older version of a package that is already installed. Fortunately, there's a special option for just this situation: --oldpackage. Let's give it a try:

# rpm -Uv --oldpackage cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

#

By using the --oldpackage option, release 3 of cdp-0.33 is history and has been replaced by release 2.

4.3.2. --force: The Big Hammer

Adding --force to an upgrade command is a way of saying "Upgrade it anyway!" In essence, it adds --replacepkgs, --replacefiles, and --oldpackage to the command. Like a big hammer, --force is an irresistible force (pun intended) that makes things happen. In fact, the only thing that will prevent an upgrade with --force from proceeding is a dependency conflict.

It pays to fully understand why you need to use --force before actually using it.

4.3.3. --noscripts: Do Not Execute Install and Uninstall Scripts

The --noscripts option prevents a package's pre- and postinstall scripts from being executed. This is no different from the option's behavior when used with RPM's install command. However, there is an additional point to consider when the option is used during an upgrade. The following example uses specially built packages that display messages when their scripts are executed by RPM:

# rpm -i bother-2.7-1.i386.rpm

This is the bother 2.7 preinstall script

This is the bother 2.7 postinstall script

#