| 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.
Usually, the situation plays out like this:
You hear about some new software that sounds pretty nifty, so you download the .rpm file 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.
rpm -U. No problem!
Fingers arched in anticipation, you launch the new version. Your computer's screen goes blank!
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
#
|
— 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 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.
The --noscripts 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
#
|
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.
| [1] | Pun intended. |
| Главная |