Table 4-1. rpm -U Command Syntax
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:
Installs the desired package.
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) 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.
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.
a modified configuration file. 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.
MD5 checksumsany 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.
The MD5 checksum of the file when it was originally installed. We'll call this the original file.
The MD5 checksum of the file as it exists at upgrade time. We'll call this the current file.
The MD5 checksum of the corresponding file in the new package. We'll call this the new file.
X, Y, and Z in place of lengthy MD5 checksums.
In this case, the file originally installed was never modified. [2] The file in the new version of the package is identical to the file on disk.
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.
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.
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.
for the new version. It leaves the existing, modified file in place.
security problem, and the new version of the file has the same fix applied to it.
— 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.
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.
… 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
|
file originally, so there is no original checksum.
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.
| [1] | Actually, there's a one in 2128 chance a change will go undetected, but for all practical purposes, it's as close to perfect as we can get. |
| [2] | Or, as some sticklers for detail may note, it may have been modified, and subsequently those modifications were undone. |
| Главная |