Chapter 4

Using RPM to Upgrade
Packages

Table 4.1. Upgrade-mode command syntax and options.

*This option behaves identically to the same option used with rpm -i. See Chapter 2, "Using RPM to Install Packages," for more information on this option.

4.1. rpm -U: What Does It Do?

If there were one RPM command that could win over friends, it would be RPM's upgrade command. After all, anyone who has ever tried to install a newer version of any software knows what a traumatic experience it can be. With RPM, though, this process is reduced to a single command: rpm -U. The rpm -U command (--upgrade is equivalent) performs two distinct
operations:

• It installs the desired package.
• It erases all older versions of the package, if any exist.

If it sounds to you like rpm -U is nothing more than an rpm -i command (see Chapter 2) followed by the appropriate number of rpm -e commands (see Chapter 3, "Using RPM to Erase Packages"), you'd be exactly right. In fact, we'll be referring to Chapters 2 and 3 as we discuss rpm -U, so if you haven't at least skimmed those chapters yet, you might want to do that now.

Although some people might think it's a cheap shot to claim that RPM performs an upgrade when in fact it's just doing the equivalent of a couple other commands, in reality it's a very smart thing to do. Carefully crafting RPM's package installation and erasure commands to do the work required during an upgrade makes RPM more tolerant of misuse by preserving important files even if an upgrade isn't being done.

If RPM had been written with a very smart upgrade command, and the install and erase commands couldn't handle upgrade situations at all, installing a package could overwrite a modified configuration file. Likewise, erasing a package would also mean that config files could be erased. Not a good situation! However, RPM's approach to upgrades makes it possible to handle even the most tricky situation—having multiple versions of a package installed simultaneously.

4.1.1. Config File Magic

While the rpm -i and rpm -e commands each do their part to keep config files straight, it is with rpm -U that the full power of RPM's config file handling shows through. There are no fewer than six different scenarios that RPM takes into account when handling config files.

In order to make the appropriate decisions, RPM needs information. The information used to decide how to handle config files is a set of three large numbers known as MD5 checksums. An MD5 checksum is produced when a file is used as the input to a complex series of mathematical operations. The resulting checksum has a unique property in that any change to the file's contents will result in a change to the checksum of that file. (Actually, there's a 1 in 2¹²⁸ chance a change will go undetected, but for all practical purposes, it's as close to perfect as we can get.) Therefore, MD5 checksums are a powerful tool for quickly determining whether two different files have the same contents.

The three checksums RPM uses to determine what should be done with a config file are

• The MD5 checksum of the file when it was originally installed. We'll call this the checksum of the original file.
• The MD5 checksum of the file as it exists at upgrade time. We'll call this the checksum of the current file.
• The MD5 checksum of the corresponding file in the new package. We'll call this the checksum of the new file.

Let's take a look at the various combinations of checksums, see what RPM will do because of them, and discuss why. In the following examples, we'll use the letters X, Y, and Z in place of lengthy MD5 checksums.

In this case, the file originally installed was never modified. Or, as some sticklers for detail may note, it may have been modified, and subsequently those modifications were undone. The file in the new version of the package is identical to the file on disk.

In this case, RPM installs the new file, overwriting the original. You might be wondering why anyone would go to the trouble of installing the new file if it's just the same as the existing one. The reason is that aspects of the file other than its name and contents might have changed. The file's ownership, for example, might be different in the new version.

The original file has not been modified, but the file in the new package is different. Perhaps the difference represents a bug fix or a new feature. It makes no difference to RPM.

In this case, RPM installs the new file, overwriting the original. This makes sense. If it didn't, RPM would never permit newer, modified versions of software to be installed! The original file is not saved because it had not been changed. A lack of changes here means that no site-specific modifications were made to the file.

Here we have a file that was changed at some point. However, the new file is identical to the existing file prior to the local modifications.

In this case, RPM takes the viewpoint that since the original file and the new file are identical, the modifications made to the original version must still be valid for the new version. It leaves the existing, modified file in place.