Библиотека сайта rus-linux.net
|Maximum RPM: Taking the Red Hat Package Manager to the Limit|
|Prev||Chapter 4. Using RPM to Upgrade Packages||Next|
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.
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:
You hear about some new software that sounds pretty nifty, so you download the
.rpmfile and install it.
The software is great! It does everything you ask for, and more. You end up using it every day for the next few months.
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!
Fingers arched in anticipation, you launch the new version. Your computer's screen goes blank!
cdp-0.33from release 3:
By using the --oldpackage option, release 3 of
cdp-0.33 is history, and has been replaced by
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  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.
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).
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.