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 on Table 4-1 at the start of this chapter shows all valid options to RPM's upgrade command, and indicates which are identical to those used with rpm -i.

--oldpackage: Upgrade To An Older Version

This option might be used a bit more by people that 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:

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.

--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 [1] that makes things happen. In fact, the only thing that will prevent a --force'ed upgrade from proceeding is a dependency conflict.

And like a big hammer, it pays to fully understand why you need to use --force before actually using it.

--noscripts: Do Not Execute Install and Uninstall Scripts

The --noscripts option prevents a package's pre- and post-install scripts from being executed. This is no different than 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
#
          

In this case, a package has been installed. As expected, its scripts are executed. Next, let's upgrade this package:

# rpm -U bother-3.5-1.i386.rpm
This is the bother 3.5 preinstall script
This is the bother 3.5 postinstall script
This is the bother 2.7 preuninstall script
This is the bother 2.7 postuninstall script
#
          

This is a textbook example of the sequence of events during an upgrade. The new version of the package is installed (as shown by the pre- and post-install scripts being executed). Finally, the previous version of the package is removed (showing the pre- and post-uninstall scripts being executed).

There are really no surprises there — it worked just the way it was meant to. This time, let's use the --noscripts option when the time comes to perform the upgrade:

# rpm -i bother-2.7-1.i386.rpm
This is the bother 2.7 preinstall script
This is the bother 2.7 postinstall script
#
          

Again, the first package is installed, and its scripts are executed. Now let's try the upgrade using the --noscripts option:

# rpm -U --noscripts bother-3.5-1.i386.rpm
This is the bother 2.7 preuninstall script
This is the bother 2.7 postuninstall script
#
          

The difference here is that the --noscripts option prevented the new package's scripts from executing. The scripts from the package being erased were still executed.

Notes

[1]

Pun intended.