📄 0170-0172.html

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




<HTML>

<HEAD>

<TITLE>Maximum RPM (RPM):Inside the Spec File: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=13 //-->

<!-- PAGES=0163-0204 //-->

<!-- UNASSIGNED1 //-->

<!-- UNASSIGNED2 //-->









<P><CENTER>

<a href="0167-0169.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0173-0175.html">Next</A>

</CENTER></P>



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







<P>require the mail-reader virtual package. It would then install without dependency problems,

if any one of several mail programs were installed. Here's what a

provides tag might look like:

</P>

<!-- CODE SNIP //-->

<PRE>

Provides: mail-reader

</PRE>

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



<B>

13.2.3.2. The requires Tag

</B>



<P>The requires tag is used to warn RPM that the package needs to have certain capabilities

available in order to operate properly. These capabilities refer to the name of another package or to

a virtual package provided by one or more packages that use the

provides tag. When the requires tag references a package name, you can include version comparisons by following

the package name with a version specification and

&lt;, &gt;, =, &gt;=  or &lt;=. To get even more specific,

you can include a package's release as well. Here's a

requires tag in action, with a specific version requirement:

</P>

<!-- CODE SNIP //-->

<PRE>

Requires: playmidi = 2.3

</PRE>

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



<P>If the requires tag needs to perform a comparison against a serial number defined with

the serial tag, the following would be the proper format:

</P>

<!-- CODE SNIP //-->

<PRE>

Requires: playmidi =S 4

</PRE>

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



<B>

13.2.3.3. The conflicts Tag

</B>



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

requires tag. The requires tag is used to specify what packages must be present in order for the current package to operate

properly. The conflicts tag is used to specify what packages cannot be installed if the current package

is to operate properly.

</P>



<P>The conflicts tag has the same format as the

requires tag&#151;namely, the tag is followed by a real or virtual package name. Like

requires, the conflicts tag also accepts version and

release specifications:

</P>

<!-- CODE SNIP //-->

<PRE>

Conflicts: playmidi = 2.3-1

</PRE>

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



<P>If the conflicts tag needs to perform a comparison against a serial number defined with

the serial tag, this would be the proper format:

</P>

<!-- CODE SNIP //-->

<PRE>

Conflicts: playmidi =S 4

</PRE>

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



<B>

13.2.3.4. The serial Tag

</B>



<P>The serial tag is another part of RPM's dependency and upgrade processing. The need for

it is somewhat obscure, but goes something like this:

</P>



<UL>

<LI>          The package being built (call it package A) uses a version numbering scheme

sufficiently obscure so that RPM cannot determine if one version is older or newer

than another version.

</UL>



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





<UL>

<LI>          Another package (package B) requires that package A be installed. More specifically,

it requires RPM to compare package A's version against a specified minimum

(or maximum) version.

</UL>



<P>Because RPM is unable to compare package A's version against the version specified by

package B, there is no way to determine if package B's dependency requirements can be met.

What to do?

</P>



<P>The serial tag provides a way to get around this tricky problem. By specifying a simple

integer serial number for each version, you are, in essence, directing how RPM interprets the

relative age of the package. The key point to keep in mind is that in order for this to work, a

unique serial number must be defined for each version of the software being packaged. In

addition, the serial number must increment along with the version. Finally, the package that

requires the serialized software needs to specify its version requirements in terms of the serial number.

</P>



<P>Does it sound like a lot of trouble? You're right! If you find yourself in the position of

needing to use this tag, take a deep breath and seriously consider changing the way you assign

version numbers. If you're packaging someone else's software, perhaps you can convince him to

make the change. Chances are, if RPM can't figure out the version number, most people can't,

either! An example of a serial tag would look something like this:

</P>



<!-- CODE SNIP //-->

<PRE>

Serial: 4

</PRE>

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



<P>Note that RPM considers a package with a serial number as newer than a package without

a serial number.

</P>



<B>

13.2.3.5. The autoreqprov Tag

</B>



<P>The autoreqprov tag is used to control the automatic dependency

processing performed when the package is being built. Normally, as each package is built, the following steps are performed:

</P>



<UL>

<LI>          All executable programs being packaged are analyzed to determine their shared

library requirements. These requirements are automatically added to the package's

requirements.

<LI>          The soname (the name used to determine compatibility between different versions

of a library) of each shared library being packaged is

automatically added to the package's list of provides information.

</UL>



<P>By doing this, RPM reduces the need for package builders to manually add dependency

information to their packages. However, there are times when RPM's automatic dependency processing may not be desirable. In those cases the

autoreqprov tag can be used to disable automatic dependency processing.

</P>

<P>To disable automatic dependency processing, add the following line:

</P>

<!-- CODE SNIP //-->

<PRE>

AutoReqProv: no

</PRE>

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



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



<P>(Note that 0 may be used instead of no.) Although RPM defaults to performing

automatic dependency processing, the effect of the

autoreqprov tag can be reversed by changing no to

yes. (1 may be used instead of yes.)

</P>



<H4>

13.2.4. Architecture- and Operating System_Specific Tags

</H4>



<P>As RPM gains popularity, more people are putting it to work on different types of

computer systems. While this would not normally be a problem, things start to get a little tricky

when either of the following situations becomes commonplace:

</P>



<UL>

<LI>          A particular

operating system is ported to several different hardware platforms,

or architectures.

<LI>          A particular architecture runs several different operating systems.

</UL>



<P>The real bind occurs when RPM is used to package software for several of these different

system environments. Without methods of controlling the build process based on

architecture and operating system, package builders that develop software for more than one

architecture or operating system will have a hard time indeed. The only alternative would be to

maintain parallel RPM build environments and accept all the coordination headaches they would entail.

</P>



<P>Fortunately, RPM makes it all easier than that. With the tags described in the following

sections, it's possible to support package building under multiple environments, all from a

single set of sources, patches, and a single spec file. For a more complete discussion of

multiarchitecture package building, see Chapter 19, &quot;Building Packages for Multiple Architectures and

Operating Systems.&quot;

</P>



<B>

13.2.4.1. The excludearch Tag

</B>



<P>The excludearch tag directs RPM to ensure that the package does not attempt to build on

the excluded architecture(s). The reasons for preventing a package from building on a certain

architecture might include the following:

</P>



<UL>

<LI>          The software has not yet been ported to the excluded architecture.

<LI>          The software would serve no purpose on the excluded architecture.

</UL>



<P>An example of the first case might be that the software was designed based on the

assumption that an integer is a 32-bit quantity. Obviously, this assumption is not valid on a 64-bit processor.

</P>



<P>In the second case, software that depended on or manipulated low-level features of a

given architecture should be excluded from building on a different architecture. Assembly

language programs would fall into this category.

</P>



<P>One or more architectures may be specified after the

excludearch tag, separated by either spaces or commas. Here is an example:

</P>

<!-- CODE SNIP //-->

<PRE>

ExcludeArch: sparc alpha

</PRE>

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



<P><CENTER>

<a href="0167-0169.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0173-0175.html">Next</A>

</CENTER></P>











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

<!-- begin footer information -->







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

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