📄 0049-0051.html

📁 linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E
💻 HTML
字号:




<HTML>

<HEAD>

<TITLE>Maximum RPM (RPM):Using RPM to Upgrade Packages:EarthWeb Inc.-</TITLE>

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
        var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>

 -->




<!-- ISBN=0672311054 //-->

<!-- TITLE=Maximum RPM (RPM)//-->

<!-- AUTHOR=Edward Bailey//-->

<!-- PUBLISHER=Macmillan Computer Publishing//-->

<!-- IMPRINT=Sams//-->

<!-- CHAPTER=04 //-->

<!-- PAGES=0045-0052 //-->

<!-- UNASSIGNED1 //-->

<!-- UNASSIGNED2 //-->









<P><CENTER>

<a href="0045-0048.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0052-0052.html">Next</A>

</CENTER></P>



<A NAME="PAGENUM-49"><P>Page 49</P></A>







<B>

4.1.1.4. Original File = X, Current File = Y, New File = Y

</B>



<P>At some point the original file was modified and those modifications happen to make the

file identical to the new file. Perhaps the modification was made to fix a security problem, and

the new version of the file has the same fix applied to it.

</P>



<P>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.

</P>



<B>

4.1.1.5. Original File = X, Current File = Y, New File = Z

</B>



<P>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.

</P>



<P>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&#151;at least the people building the new package

should have ensured that it does. The modified original file is an unknown: It might work with

the new package and it might not. So RPM installs the new file.

</P>



<P>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:

</P>

<!-- CODE SNIP //-->

<PRE>

warning: /etc/skel/.bashrc saved as /etc/skel/.bashrc.rpmsave

</PRE>

<!-- END CODE SNIP //-->



<B>

4.1.1.6. Original File = None , Current File = ??, New File = ??

</B>



<P>While RPM doesn't use checksums in this particular case, we'll describe it in those terms

for the sake of consistency. In this instance, RPM had not installed the file originally, so there

is no original checksum.

</P>



<P>Because the file had not originally been installed as part of a package, there is no way for

RPM to determine whether 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.

</P>



<P>When this happens, RPM renames the file

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.

</P>



<P>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 postupgrade work for the system administrator. Even

in those cases, many times the modified files are not worth saving and can be deleted.

</P>



<A NAME="PAGENUM-50"><P>Page 50</P></A>







<H3><A NAME="ch04_ 4">

4.2. Upgrading a Package

</A></H3>



<P>The most basic version of the rpm -U command is simply

rpm -U, followed by the name of an .rpm package file:

</P>

<!-- CODE SNIP //-->

<PRE>

# rpm -U eject-1.2-2.i386.rpm

#

</PRE>

<!-- END CODE SNIP //-->



<P>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. (For more information on RPM's use

of URLs, see section 2.2.1 in Chapter 2.)

</P>



<H4><A NAME="ch04_ 5">

4.2.1. rpm -U's Dirty Little Secret

</A></H4>



<P>Well, in the preceding example, 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.

</P>



<P>This is another, more concrete, example of the strength of RPM's method of performing

upgrades. Because 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, &quot;Uh, do the right thing....&quot;

</P>



<H3><A NAME="ch04_ 6">

4.3. They're Nearly Identical

</A></H3>



<P>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 at the beginning of this chapter shows all valid options to RPM's upgrade command and indicates which are

identical to those used with rpm -i.

</P>



<H4><A NAME="ch04_ 7">

4.3.1. --oldpackage: Upgrade to an Older Version

</A></H4>



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

</P>



<OL>

<LI>     You hear about some new software that sounds pretty nifty, so you download the

.rpm file and install it.

<LI>     The software is great! It does everything you ask for and more. You end up using

it every day for the next few months.

</OL>





<A NAME="PAGENUM-51"><P>Page 51</P></A>



<OL START=3>



<LI>     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!

<LI>     Fingers arched in anticipation, you launch the new version. Your computer's

screen goes blank!

</OL>



<P>Looks like a bug in the new version. Now what do you do? Hmmm. Maybe

you can just &quot;upgrade&quot; to the older version. Let's try to go back to release 2 of

cdp-0.33 from release 3:

</P>

<!-- CODE //-->

<PRE>

# 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

#

</PRE>

<!-- END CODE //-->



<P>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:

</P>

<!-- CODE SNIP //-->

<PRE>

# rpm -Uv --oldpackage cdp-0.33-2.i386.rpm

Installing cdp-0.33-2.i386.rpm

#

</PRE>

<!-- END CODE SNIP //-->



<P>By using the --oldpackage option, release 3 of

cdp-0.33 is history and has been replaced by release 2.

</P>



<H4><A NAME="ch04_ 8">

4.3.2. --force: The Big Hammer

</A></H4>



<P>Adding --force to an upgrade command is a way of saying &quot;Upgrade it anyway!&quot; In essence,

it adds --replacepkgs, --replacefiles, and

--oldpackage to the command. Like a big hammer,

--force is an irresistible force (pun intended) that makes things happen. In fact, the only

thing that will prevent an upgrade with --force from proceeding

is a dependency conflict.

</P>



<P>It pays to fully understand why you need to use

--force before actually using it.

</P>



<H4><A NAME="ch04_ 9">

4.3.3. --noscripts: Do Not Execute Install and Uninstall Scripts

</A></H4>



<P>The --noscripts option prevents a package's pre- and postinstall scripts from being

executed. This is no different from 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:

</P>

<!-- CODE SNIP //-->

<PRE>

# rpm -i bother-2.7-1.i386.rpm

This is the bother 2.7 preinstall script

This is the bother 2.7 postinstall script

#

</PRE>

<!-- END CODE SNIP //-->



<P><CENTER>

<a href="0045-0048.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0052-0052.html">Next</A>

</CENTER></P>











</td>
</tr>
</table>

<!-- begin footer information -->







</body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -