1000pt
| rpm -U ( or - -upgrade) options file1.rpm ... fileN.rpm | ||
| Parameters | ||
|
file1.rpm ... fileN.rpm | One or more RPM package files (URLs OK) | |
|
Upgrade--specific Options | Page | |
|
-h (or - -hash) | Print hash marks (``#'') during upgrade[fnsymbol{footnote}] | [*] |
|
- -oldpackage | Permit ``upgrading'' to an older package | [*] |
|
- -test | Perform upgrade tests only[fnsymbol{footnote}] | [*] |
|
- -excludedocs | Do not install documentation[fnsymbol{footnote}] | [*] |
|
- -includedocs | Install documentation[fnsymbol{footnote}] | [*] |
|
- -replacepkgs | Replace a package with a new copy of itself[fnsymbol{footnote}] | [*] |
|
- -replacefiles | Replace files owned by another package[fnsymbol{footnote}] | [*] |
|
- -force | Ignore package and file conflicts | [*] |
|
- -percent | Print percentages during upgrade[fnsymbol{footnote}] | [*] |
|
- -noscripts | Do not execute pre- and post-install scripts | [*] |
|
- -prefix <path> | Relocate package to <path> if possible[fnsymbol{footnote}] | [*] |
|
- -ignorearch | Do not verify package architecture[fnsymbol{footnote}] | [*] |
|
- -ignoreos | Do not verify package operating system[fnsymbol{footnote}] | [*] |
|
- -nodeps | Do not check dependencies[fnsymbol{footnote}] | [*] |
|
- -ftpproxy <host> | Use <host> as the FTP proxy[fnsymbol{footnote}] | [*] |
|
- -ftpport <port> | Use <port> as the FTP port[fnsymbol{footnote}] | [*] |
|
General Options | Page | |
|
-v | Display additional information[fnsymbol{footnote}] | [*] |
|
-vv | Display debugging information[fnsymbol{footnote}] | [*] |
|
- -root <path> | Set alternate root to <path>[fnsymbol{footnote}] | [*] |
|
- -rcfile <rcfile> | Set alternate rpmrc file to <rcfile>[fnsymbol{footnote}] | [*] |
|
- -dbpath <path> | Use <path> to find the RPM database[fnsymbol{footnote}] | [*] |
|
| ||
If there was 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:
If it sounds to you like rpm -U is nothing more than an rpm -i command (see chapter [*]) followed by the appropriate number of rpm -e commands, (see chapter [*]) you'd be exactly right. In fact, we'll be referring back to those chapters as we discuss rpm -U, so if you haven't skimmed those chapters yet, you might want to do that now.
While 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 of other commands, in fact, it's a very smart thing to do. By carefully crafting RPM's package installation and erasure commands to do the work required during an upgrade, it 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 install simultaneously.
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 less 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.1 Therefore, MD5 checksums are a powerful tool for quickly determining whether two different files have the same contents or not.
In the previous paragraph, we stated that RPM uses three different MD5 checksums to determine what should be done with a config file. The three checksums are:
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, RPM installs the new file, overwriting the original. You may be wondering why 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.
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, since it had not been changed. A lack of changes here means that no site-specific modifications were made to the file.
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.
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.
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 insured that it does. The modified original file is an unknown: it might work with the new package, 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
These five scenarios cover just about every possible circumstance, save one. The missing scenario?
Because the file had not originally been installed as part of a package, there is no way for RPM to determine if 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 to 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 post-upgrade work for the system administrator. Even in those cases, many times the modified files are not worth saving and can be deleted.
The most basic version of the rpm -U command is simply ``rpm -U'', followed by the name of a .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.3
Well, in the example above, 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. Since 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''...
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 page [*] 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.
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.
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 force4 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.
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.