📄 0173-0175.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="0170-0172.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0176-0178.html">Next</A>

</CENTER></P>



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



<P>In this example, RPM would not attempt to build the package on either the Sun SPARC

or Digital Alpha/AXP architectures. The package could build on any other architectures,

however. If a build is attempted on an excluded architecture, the following message will be

displayed, and the build will fail:

</P>

<!-- CODE SNIP //-->

<PRE>

# rpm -ba cdplayer-1.0.spec

Arch mismatch!

cdplayer-1.0.spec doesn't build on this architecture

#

</PRE>

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



<P>Note that if your goal is to ensure that a package will only build on one architecture, you

should use the exclusivearch tag.

</P>



<B>

13.2.4.2. The exclusivearch Tag

</B>



<P>The exclusivearch tag is used to direct RPM to ensure that the package is only built on

the specified architecture(s). The reasons for this are similar to the those

mentioned in section 13.2.5.1. However, the

exclusivearch tag is useful when the package builder needs to

ensure that only the specified architectures will build the package. This tag ensures that no future

architectures will mistakenly attempt to build the package. This would not be the case if

the excludearch tag were used to specify every architecture known at the time the package is built.

</P>



<P>The syntax of the exclusivearch tag is identical to that of

excludearch:

</P>

<!-- CODE SNIP //-->

<PRE>

ExclusiveArch: sparc alpha

</PRE>

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



<P>In this example, the package will only build on a Sun SPARC or Digital Alpha/AXP system.

</P>



<P>Note that if your goal is to ensure that a package will not build on specific architectures,

you should use the excludearch tag.

</P>



<B>

13.2.4.3. The excludeos Tag

</B>



<P>The excludeos tag is used to direct RPM to ensure that the

package does not attempt to build on the excluded operating system(s). This is usually necessary when a package is to be built

on more than one operating system, but it is necessary to keep a particular operating system

from attempting a build.

</P>



<P>Note that if your goal is to ensure that a package will only build on one operating system,

you should use the exclusiveos tag. Here's a sample

excludeos tag:

</P>

<!-- CODE SNIP //-->

<PRE>

ExcludeOS: linux irix

</PRE>

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



<B>

13.2.4.4. The exclusiveos Tag

</B>



<P>The exclusiveos tag has the same syntax as

excludeos, but it has the opposite logic. The

exclusiveos tag is used to denote which operating system(s) should be exclusively

permitted to build the package. Here's exclusiveos in action:

</P>

<!-- CODE SNIP //-->

<PRE>

ExclusiveOS: linux

</PRE>

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



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



<P>Note that if your goal is to ensure that a package will not build on a specific operating

system, you should use the excludeos tag.

</P>



<H4>

13.2.5. Directory-Related Tags

</H4>



<P>A number of tags are used to specify directories and paths that are used in various phases

of RPM's build and install processes. There's not much more to say collectively about these

tags, so let's dive right in and look them over.

</P>



<B>

13.2.5.1. The prefix Tag

</B>



<P>The prefix tag is used when a relocatable package is to be built. A relocatable package can

be installed normally or can be installed in a user-specified directory, by using RPM's

--prefix install-time option. The data specified after the prefix tag should be the part of the

package's path that may be changed during installation. For example, if the following prefix line

were included in a spec file:

</P>

<!-- CODE SNIP //-->

<PRE>

Prefix: /opt

</PRE>

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



<P>and the following file were specified in the spec file's

%files list:

</P>

<!-- CODE SNIP //-->

<PRE>

/opt/blather/foonly

</PRE>

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



<P>then the file foonly would be installed in

/opt/blather if the package was installed

normally. It would be installed in

/usr/local/blather if the package was installed with the

--prefix /usr/local option.

</P>



<P>For more information about creating relocatable packages, see Chapter 15, &quot;Making

a Relocatable Package.&quot;

</P>



<B>

13.2.5.2. The buildroot Tag

</B>



<P>The buildroot tag is used to define an alternate build root. The

name is a bit misleading because the build root is actually used when the software is installed during the build process.

In order for a build root to be defined and actually used, a number of issues must be taken

into account. These issues are covered in Chapter 16, &quot;Making a Package That Can Build

Anywhere.&quot; This is what a buildroot tag would look like:

</P>

<!-- CODE SNIP //-->

<PRE>

BuildRoot: /tmp/cdplayer

</PRE>

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



<P>The buildroot tag can be overridden at build time by using the

--buildroot command-line option.

</P>



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







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

13.2.6. Source and Patch Tags

</A></H4>



<P>In order to build and package software, RPM needs to know where to find the original

sources. But it's not quite that simple. There might be more than one set of sources that need to be

part of a particular build. In some cases, it might be necessary to prevent some sources from

being packaged.

</P>



<P>And then there is the matter of patches. It's likely that changes will need to be made to

the sources, so it's necessary to specify a patch file. But the same issues that apply to source

specifications are also applicable to patches. There might be more than one set of patches required.

</P>



<P>The tags that are described in the following sections are crucial to RPM, so it pays to have

a firm grasp of how they are used.

</P>



<B>

13.2.6.1. The source Tag

</B>



<P>The source tag is central to nearly every spec file. Although it has only one piece of data

associated with it, it performs two functions:

</P>



<UL>

<LI>          It shows where the software's

developer has made the original sources available.

<LI>          It gives RPM the name of the original source file.

</UL>



<P>While there is no hard-and-fast rule for the first function, it's generally considered best to

put this information in the form of a URL. The URL should point

directly to the source file itself. This is because of the source tag's second function.

</P>



<P>As mentioned previously, the source tag also needs to direct RPM to the source file on

the build system. How does it do this? There's only one requirement, and it is ironclad: The

source filename must be at the end of the line as the final element in a path. Here's an example:

</P>

<!-- CODE SNIP //-->

<PRE>

Source: ftp://ftp.gnomovision.com/pub/cdplayer-1.0.tgz

</PRE>

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



<P>Given this source line, RPM will search its

SOURCES directory for cdplayer-1.0.tgz. Everything prior to the filename is ignored by RPM. It's there strictly for any interested humans.

</P>



<P>A spec file may contain more than one source tag. This is necessary for those cases where

the software being packaged is contained in more than one source file. However, the source

tags must be uniquely identified. This is done by appending a number to the end of the tag

itself. In fact, RPM does this internally for the first source tag in a spec file, in essence turning it

into source0. Therefore, if a package contains two source files, they may either be specified this way:

</P>

<!-- CODE SNIP //-->

<PRE>

Source: blather-4.5.tar.gz

Source1: bother-1.2.tar.gz

</PRE>

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



<P>or this way:

</P>

<!-- CODE SNIP //-->

<PRE>

Source0: blather-4.5.tar.gz

Source1: bother-1.2.tar.gz

</PRE>

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



<P><CENTER>

<a href="0170-0172.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0176-0178.html">Next</A>

</CENTER></P>











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

<!-- begin footer information -->







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

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