📄 0212-0214.html

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




<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="0209-0211.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="../ch15/0215-0218.html">Next</A>

</CENTER></P>



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







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

14.3.3. The provides Tag

</A></H4>



<P>Now that you've seen how it's possible to require a package using the

requires tag, you're probably expecting that you'll need to use the

provides tag in every single package. After all,

RPM has to get those package names from somewhere, right?

</P>



<P>While it is true that RPM needs to have the package names available, the

provides tag is normally not required. It would actually be redundant because the RPM database already

contains the name of every package installed. There's no need to duplicate that information.

</P>



<P>But wait! We said earlier that manual dependency requirements are always represented in

terms of packages. If RPM doesn't require the package builder to use the

provides tag to provide the package name, then what is the

provides tag used for?

</P>



<B>

14.3.3.1. Virtual Packages

</B>



<P>Enter the virtual package. A virtual package is nothing more than a name specified with

the provides tag. Virtual packages are handy when a package requires a certain capability, and

that capability can be provided by any one of several packages. Here's an example: In order to

work properly, sendmail needs a local delivery agent to handle mail delivery. There are a number

of different local delivery agents available:

sendmail will work just fine with any of them.

</P>



<P>In this case, it doesn't make sense to force the use of a particular local delivery agent; as long

as one's installed, sendmail's requirements will have been satisfied. So

sendmail's package builder adds the following line to

sendmail's spec file:

</P>

<!-- CODE SNIP //-->

<PRE>

requires: lda

</PRE>

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



<P>There is no package with that name available, so

sendmail's requirements must be met with a virtual package. The creators of the various local delivery agents indicate that their

packages satisfy the requirements of the lda virtual package by adding the following line to their

packages' spec files:

</P>

<!-- CODE SNIP //-->

<PRE>

provides: lda

</PRE>

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

<BR>

<P>



<CENTER>

<TABLE BGCOLOR="#FFFF99">

<TR><TD><B>

NOTE

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

<TR><TD>

<BLOCKQUOTE>

Note that virtual packages may not have version numbers.

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

</TABLE></CENTER>

</P>

<P>Now, when sendmail is installed, as long as there is a package installed that provides the

lda virtual package, there will be no problem.

</P>



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







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

14.4. To Summarize

</A></H3>



<P>RPM's dependency processing is based on tracking the capabilities a package provides and

the capabilities a package requires. A package's requirements can come from two places:

</P>



<UL>

<LI>          Shared library requirements,

automatically determined by RPM

<LI>          The

requires tag line, manually added to the package's spec file

</UL>



<P>These requirements can be viewed by using RPM's

--requires query option. A specific requirement can be viewed by using the

--whatrequires query option. Both options are

fully described in Chapter 5, &quot;Getting Information About Packages.&quot;

</P>



<P>The capabilities a package provides can come from three places:

</P>



<UL>

<LI>          Shared library

sonames, automatically determined by RPM

<LI>          The

provides tag line, manually added to the package's spec file

<LI>          The package's name (and optionally, the version/serial number)

</UL>



<P>The first two types of information can be viewed by using RPM's

--provides query option. A specific capability can be viewed by using the

--whatprovides query option. Both options are fully described in Chapter 5.

</P>



<P>The package name and version are not considered capabilities that are explicitly

provided. Therefore, if a search using --provides or

--whatprovides comes up dry, try simply looking for a package by that name.

</P>



<P>As you've probably gathered by now, using manual dependencies requires some level of

synchronization between packages. This can be tricky, particularly if you're not responsible

for both packages. But RPM's dependency processing can make life easier for your users.

</P>



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

<BR><BR>





<P><CENTER>

<a href="0209-0211.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="../ch15/0215-0218.html">Next</A>

</CENTER></P>











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

<!-- begin footer information -->







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

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