0209-0211.html

来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 301 行
HTML
301 行




<HTML>

<HEAD>

<TITLE>Maximum RPM (RPM):Adding Dependency Information to a Package: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=14 //-->

<!-- PAGES=0205-0214 //-->

<!-- UNASSIGNED1 //-->

<!-- UNASSIGNED2 //-->









<P><CENTER>

<a href="0205-0208.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0212-0214.html">Next</A>

</CENTER></P>



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



<!-- CODE SNIP //-->

<PRE>



&lt;ctrl-d&gt;

libc.so.5

#

</PRE>

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



<P>Okay, so /lib/libc.so.5.3.12's soname is

libc.so.5. Let's see if the libc package really

does provide the libc.so.5 soname:

</P>



<!-- CODE SNIP //-->

<PRE>

# rpm -q --provides libc

libm.so.5

libc.so.5

#

</PRE>

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



<P>Yes, there it is, along with the soname of another library contained in the package. In this

way, RPM can ensure that any package requiring

libc.so.5 will have a compatible library available as long as the

libc package, which provides libc.so.5, is installed.

</P>



<P>In most cases, automatic dependencies are enough to fill the bill. However, there are

circumstances when the package builder has to manually add dependency information to a

package. Fortunately, RPM's approach to manual dependencies is both simple and flexible.

</P>



<H4>

14.2.3. The autoreqprov Tag: Disable Automatic

Dependency Processing

</H4>



<P>There may be times when RPM's automatic dependency processing is not desired.

In these cases, the autoreqprov tag may be used to disable it. This tag takes a

yes/no or 0/1 value. For example, to disable automatic dependency processing, the following line may be used:

</P>

<!-- CODE SNIP //-->

<PRE>

AutoReqProv: no

</PRE>

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



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

14.3. Manual Dependencies

</A></H3>



<P>You might have noticed that we've been using the words

requires and provides to describe the dependency relationships between packages. As it turns out, these are the exact words used

in spec files to manually add dependency information. Let's look at the first tag:

requires.

</P>



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

14.3.1. The requires Tag

</A></H4>



<P>We've been deliberately vague when discussing exactly what it is that a package requires.

Although we've used the word capabilities, in fact, manual dependency requirements are

always represented in terms of packages. For example, if package

foo requires that package bar is installed, it's only necessary to add the following line to

foo's spec file:

</P>

<!-- CODE SNIP //-->

<PRE>

requires: bar

</PRE>

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



<P>Later, when the foo package is being installed, RPM will consider

foo's dependency requirements met if any version of package

bar is already installed. As long as the requiring and

the

</P>



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







<P>providing packages are installed using the same invocation of RPM, the dependency

checking will succeed. For example, the command rpm -ivh

*.rpm will properly check for dependencies, even if the requiring package ends up being installed before the providing package.

</P>



<P>If more than one package is required, they can be added to the

requires tag, one after another, separated by commas and/or spaces. So if package

foo requires packages bar and baz, the following line will do the trick:

</P>



<!-- CODE SNIP //-->

<PRE>

requires: bar, baz

</PRE>

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



<P>As long as any version of bar and baz is installed,

foo's dependencies will be met.

</P>



<B>

14.3.1.1. Adding Version Requirements

</B>



<P>When a package has slightly more stringent needs, it's possible to require certain versions of

a package. All that's necessary is to add the desired version number, preceded by one of the

following comparison operators:



<TABLE>



<TR><TD>

&lt;

</TD><TD>

Requires a package with a version less than the specified version.

</TD></TR><TR><TD>

&lt;=

</TD><TD>

Requires a package with a version less than or equal to the specified version.

</TD></TR><TR><TD>

=

</TD><TD>

Requires a package with a version equal to the specified version.

</TD></TR><TR><TD>

&gt;=

</TD><TD>

Requires a package with a version greater than or equal to the specified version.

</TD></TR><TR><TD>

&gt;

</TD><TD>

Requires a package with a version greater than the specified version.

</TD></TR></TABLE>



<P>Continuing with our example, let's suppose that the required version of package

bar actually needs to be at least 2.7, and that the

baz package must be version 2.1&#151;no other version

will do. Here's what the requires tag line would look like:

</P>

<!-- CODE SNIP //-->

<PRE>

requires: bar &gt;= 2.7, baz = 2.1

</PRE>

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



<P>We can get even more specific and require a particular release of a package:

</P>

<!-- CODE SNIP //-->

<PRE>

requires: bar &gt;= 2.7-4, baz = 2.1-1

</PRE>

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



<B>

14.3.1.2. When Version Numbers Aren't Enough

</B>



<P>You might think that with all these features, RPM's dependency processing can handle

every conceivable situation. You'd be right, except for the problem of version numbers. RPM

needs to be able to determine which version numbers are more recent than others in order to

perform its version comparisons.

</P>



<P>It's pretty simple to determine that version 1.5 is older than version 1.6. But what about

2.01 and 2.1? Or 7.6a and 7.6? There's no way for RPM to keep up with all the different

version-numbering schemes in use. But there is a solution; there are two, in fact.

</P>



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







<B>

14.3.1.2.1. Solution Number 1: Serial Numbers

</B>



<P>When RPM can't decipher a package's version number, it's time to pull out the

serial tag. This tag is used to help RPM determine version number ordering. Here's a sample

serial

tag line:

</P>



<!-- CODE SNIP //-->

<PRE>

Serial: 42

</PRE>

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



<P>This line indicates that the package has the serial number 42. What does the 42 mean?

Only that this version of the package is older than the same package with the serial number 41,

but younger than the same package with the serial number 43. If you think of serial numbers

as being nothing more than very simple version numbers, you'll be on the mark.

</P>



<P>In order to direct RPM to look at the serial number instead of the version number when

doing dependency checking, it's necessary to append an

S to the end of the conditional operator in the

requires tag line. So if a package requires package

foo to have a serial number equal to 42, the following tag line would be used:

</P>

<!-- CODE SNIP //-->

<PRE>

Requires: foo =S 42

</PRE>

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



<P>If the foo package needs to have a serial number greater than or equal to 42, this line

would work:

</P>

<!-- CODE SNIP //-->

<PRE>

Requires: foo &gt;=S 42

</PRE>

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



<P>It might seem that using serial numbers is a lot of extra trouble, and you're right. But there

is an alternative.

</P>



<B>14.3.1.2.2. Solution Number 2: Just Say No!

</B>



<P>If you have the option between changing the software's version-numbering scheme or

using serial numbers in RPM, consider changing the version-numbering scheme. Chances are, if

RPM can't figure it out, most of the people using your software can't, either. But in case you

aren't the author of the software you're packaging, and its version numbering scheme is giving

RPM fits, the serial tag can help you out.

</P>



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

14.3.2. The conflicts Tag

</A></H4>



<P>The conflicts tag is the logical complement to the

requires tag. It is used to specify which packages conflict with the current package. RPM will not permit conflicting packages to

be installed unless overridden with the --nodeps option.

</P>



<P>The conflicts tag has the same format as

requires. It accepts a real or virtual package

name and can optionally include version and release specifications or a serial number.

</P>



<P><CENTER>

<a href="0205-0208.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0212-0214.html">Next</A>

</CENTER></P>











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

<!-- begin footer information -->







</body></html>
0209-0211.html - 源码说明

本页面展示了「linux-unix130.linux.and.unix.ebooks130 linux and unix ebookslinuxLearning Linux - Collection of 12 E」中的 0209-0211.html 源码文件，采用 HTML 编程语言编写，共 301 行代码。您可以在线阅读完整代码内容，也可以返回资源详情页下载完整源码包进行本地学习和开发。
虫虫下载站收录了大量与linux相关的技术资源，包括源代码、技术文档、电路图等，是电子工程师和嵌入式开发者的专业学习平台。
⌨️ 快捷键说明

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