📄 0201-0203.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="0198-0200.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0204-0204.html">Next</A>

</CENTER></P>



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







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

13.7.1. -n &lt;string&gt;: Use &lt;string&gt; As the Entire

Subpackage Name

</A></H4>



<P>As mentioned earlier, the name of a subpackage normally includes the main package

name. When the -n option is added to the %package directive, it directs RPM to use the name

specified on the %package line as the entire package name. In the preceding example, the

following %package line would create a subpackage named

foonly-doc:

</P>

<!-- CODE SNIP //-->

<PRE>

%package doc

</PRE>

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



<P>The following %package line would create a subpackage named

doc:

</P>

<!-- CODE SNIP //-->

<PRE>

%package -n doc

</PRE>

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



<P>The %package directive plays another role in subpackage building: to act as a place to

collect tags that are specific to a given subpackage. Any tag placed after a

%package directive will apply only to that subpackage.

</P>



<P>Finally, the name string specified by the

%package directive is also used to denote which

parts of the spec file are a part of that subpackage. This is done by including the string (along

with the -n option, if present on the %package line) on the starting line of the section that is to

be subpackage specific. Here's an example:

</P>

<!-- CODE SNIP //-->

<PRE>

...

%package -n bar

...

%post -n bar

...

</PRE>

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



<P>In this heavily edited spec file segment, a subpackage called

bar has been defined. Later in the file is a postinstall script. Because it has subpackage

bar's name on the %post line, the postinstall script will be part of the

bar subpackage only.

</P>



<P>For more information on building subpackages, see Chapter 18, &quot;Creating Subpackages.&quot;

</P>



<H3><A NAME="ch13_ 14">

13.8. Conditionals

</A></H3>



<P>While the exclude and exclusive tags

(excludearch, exclusivearch, excludeos, and

exclusiveos) provide some control over whether a package will be built on a given architecture and/or

operating system, that control is still rather coarse.

</P>



<P>For example, what should be done if a package will build under multiple architectures,

but requires slightly different %build scripts? Or what if a package requires a certain set of files

under one operating system, and an entirely different set under another operating system? The

architecture and operating system_specific tags discussed earlier in the chapter do nothing to

help in such situations. What can be done?

</P>



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







<P>One approach would be to simply create different spec files for each architecture or

operating system. While it would certainly work, this approach has two problems:

</P>



<UL>

<LI>          More work. The existence of multiple spec files for a given package means that

the effort required to make any changes to the package is multiplied

by however many different spec files there are.

<LI>          More chance for mistakes. If any work needs to be done to the spec files, the fact

they are separate means it is that much easier to forget to make the necessary changes

to each one. There is also the chance of introducing mistakes each time changes

are made.

</UL>



<P>The other approach is to somehow permit the conditional inclusion of architecture- or

</P>



<P>operating system_specific sections of the spec file. Fortunately, the RPM designers chose

this approach, and it makes multiplatform package building easier and less prone to mistakes.

</P>



<P>We discuss multiplatform package building in depth in Chapter 19. For now, let's take a

quick look at RPM's conditionals.

</P>



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

13.8.1. The %ifarch Conditional

</A></H4>



<P>The %ifarch conditional is used to begin a section of the spec file

that is architecture specific. It is followed by one or more architecture specifiers, each separated by commas or

whitespace. Here is an example:

</P>

<!-- CODE SNIP //-->

<PRE>

%ifarch i386 sparc

</PRE>

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



<P>The contents of the spec file following this line would be processed only by Intel x86 or

Sun SPARC_based systems. However, if only this line were placed in a spec file, this is what

would happen if a build were attempted:

</P>

<!-- CODE SNIP //-->

<PRE>

# rpm -ba cdplayer-1.0.spec

Unclosed %if

Build failed.

#

</PRE>

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



<P>The problem that surfaced here is that any conditional must be closed by using either

%else or %endif. We'll be covering them a bit later in the chapter.

</P>



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

13.8.2. The %ifnarch Conditional

</A></H4>



<P>The %ifnarch conditional is used in a similar fashion to

%ifarch, except that the logic is reversed. If a spec file contains a conditional block starting with

%ifarch alpha, that block would be processed only if the build were being done on a Digital Alpha/AXP-based system.

However, if the conditional block started with %ifnarch

alpha, that block would be processed only if the build were not being done on an Alpha.

</P>



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







<P>Like %ifarch, %ifnarch can be followed by one or more architectures and must be closed

by %else or %endif.

</P>



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

13.8.3. The %ifos Conditional

</A></H4>



<P>The %ifos conditional is used to control RPM's spec file processing based on the build

system's operating system. It is followed by one or more operating system names. A conditional

block started with %ifos must be closed by %else or

%endif. Here's an example:

</P>

<!-- CODE SNIP //-->

<PRE>

%ifos linux

</PRE>

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



<P>The contents of the spec file following this line would be processed only if the build were

done on a Linux system.

</P>



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

13.8.4. The %ifnos Conditional

</A></H4>



<P>The %ifnos conditional is the logical complement to

%ifos&#151;that is, if a conditional starting with the line

%ifnos irix is present in a spec file, the file contents after the

%ifnos will not be processed if the build system is running Irix. As always, a conditional block starting with

%ifnos must be closed by %else or %endif.

</P>



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

13.8.5. The %else Conditional

</A></H4>



<P>The %else conditional is placed between an %if conditional of some persuasion, and an

%endif. It is used to create two blocks of spec file statements, only one of which will be used in

any given case. Here's an example:

</P>

<!-- CODE //-->

<PRE>

%ifarch alpha

make RPM_OPT_FLAGS=&quot;$RPM_OPT_FLAGS -I .&quot;

%else

make RPM_OPT_FLAGS=&quot;$RPM_OPT_FLAGS&quot;

%endif

</PRE>

<!-- END CODE //-->



<P>When a build is performed on a Digital Alpha/AXP, some additional flags are added to

the make command. On all other systems, these flags are not added.

</P>



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

13.8.6. The %endif Conditional

</A></H4>



<P>A %endif is used to end a conditional block of spec file statements. It can follow

one of the %if conditionals, or the %else. The

%endif is always needed after a conditional; otherwise the

build will fail. Here's a short conditional block, ending with an

%endif:

</P>

<!-- CODE SNIP //-->

<PRE>

%ifarch i386

make INTELFLAG=-DINTEL

%endif

</PRE>

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



<P>In this example, we see that the conditional block started with an

%ifarch and ended with an %endif.

</P>



<P><CENTER>

<a href="0198-0200.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0204-0204.html">Next</A>

</CENTER></P>











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

<!-- begin footer information -->







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

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