📄 0247-0250.html
字号:
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):Creating Subpackages: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=18 //-->
<!-- PAGES=0247-0262 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch17/0245-0246.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0251-0254.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-247"><P>Page 247</P></A>
<H3><A NAME="ch18_ 1">
Chapter 18
</A></H3>
<H2>
Creating Subpackages
</H2>
<A NAME="PAGENUM-248"><P>Page 248</P></A>
<P>In this chapter, we will explore one of RPM's more interesting capabilities: the capability
to create subpackages.
</P>
<H3><A NAME="ch18_ 2">
18.1. What Are Subpackages?
</A></H3>
<P>Very simply put, a subpackage is one of several package files created from a single spec file.
RPM has the ability to create a main package, along with one or more subpackages. Subpackages
can also be created without the main package. It's all up to the package builder.
</P>
<H3><A NAME="ch18_ 3">
18.2. Why Are Subpackages Needed?
</A></H3>
<P>If all the software in the world followed the usual "one source, one binary" structure,
there would be no need for subpackages. After all, RPM handles the building and packaging of
a program into a single package file just fine.
</P>
<P>But software doesn't always conform to this simplistic structure. It's not unusual for
software to support two or more different modes of operation. A client/server program, for
example, comes in two flavors: a client and a server.
</P>
<P>And it can get more complicated than that. Sometimes software relies on another program
so completely that the two cannot be built separately. The result is often several packages.
</P>
<P>Although it is certainly possible that some convoluted procedure could be devised to force
these kinds of software into a single-package structure, it makes more sense to let RPM manage
the creation of subpackages. Why? From the package builder's viewpoint, the main reason to
use subpackages is to eliminate any duplication of effort.
</P>
<P>When using subpackages, there's no need to maintain separate spec files and endure the
resulting headaches when new versions of the software become available. By keeping everything
in one spec file, new software versions can be quickly integrated, and every related
subpackage can be rebuilt with a single command.
</P>
<P>But that's enough of the preliminaries. Let's see how subpackages are created.
</P>
<H3><A NAME="ch18_ 4">
18.3. Our Sample Spec File: Subpackages Galore!
</A></H3>
<P>Throughout this chapter, we'll be constructing a spec file that will consist of a number
of subpackages. Let's start by listing the spec file's requirements:
</P>
<UL>
<LI> The main package name is to be
foo.
<LI> The version is to be 2.7.
</UL>
<A NAME="PAGENUM-249"><P>Page 249</P></A>
<UL>
<LI> There are three subpackages:
<UL>
<LI> The server subpackage,
to be called foo-server
<LI> The client subpackage, to be called
foo-client
<LI> The
baz development library subpackage, to be called bazlib
</UL>
<LI> The
bazlib subpackage has a version 5.6.
<LI> Each subpackage will have its own
summary and description tags.
</UL>
<P>Every spec file starts with a preamble. In this case, the preamble will contain the following tags:
</P>
<!-- CODE //-->
<PRE>
Name: foo
Version: 2.7
Release: 1
Source: foo-2.7.tgz
CopyRight: probably not
Summary: The foo app, and the baz library needed to build it
Group: bogus/junque
%description
This is the long description of the foo app, and the baz library needed to
build it...
</PRE>
<!-- END CODE //-->
<P>As you can see, there's nothing different here: This is an ordinary spec file so far. Let's
delve into things a bit more and see what we'll need to add to this spec file to create the
subpackages we require.
</P>
<H3><A NAME="ch18_ 5">
18.4. Spec File Changes for Subpackages
</A></H3>
<P>The creation of subpackages is based strictly on the contents of the spec file. This doesn't
mean that you'll have to learn an entirely new set of tags, conditionals, and directives in order
to create subpackages, however. In fact, you'll only need to learn one.
</P>
<P>The primary change to a spec file is structural and starts with the definition of a preamble
for each subpackage.
</P>
<H4><A NAME="ch18_ 6">
18.4.1. The Subpackage's Preamble
</A></H4>
<P>When we introduced RPM package building in Chapter 10, "The Basics of Developing
with RPM," we said that every spec file contains a preamble. The preamble contains a variety of
tags that define all sorts of information about the package. In a single-package situation, the
preamble must be at the start of the spec file. The spec file we're creating will have one there, too.
</P>
<P>When you're creating a spec file that will build subpackages, each subpackage also needs a
preamble of its own. These subpreambles need only define information for the subpackage
when that information differs from what is defined in the main preamble. For example, if we
wanted to define an installation prefix for a subpackage, we would add the appropriate
prefix tag to that subpackage's preamble. That subpackage would then be relocatable.
</P>
<A NAME="PAGENUM-250"><P>Page 250</P></A>
<P>In a single-package spec file, nothing explicitly identifies the preamble other than its
position at the top of the file. For subpackages, however, we need to be a bit more explicit. So we
use the %package directive to identify the preamble for each subpackage.
</P>
<H5><A NAME="ch18_ 7">
18.4.1.1. The %package Directive
</A></H5>
<P>The %package directive actually performs two functions. As mentioned, it is used to denote
the start of a subpackage's preamble. It also plays a role in forming the subpackage's name.
For example, let's say the main preamble contains the following
name tag:
</P>
<!-- CODE SNIP //-->
<PRE>
name: foo
</PRE>
<!-- END CODE SNIP //-->
<P>Later in the spec file, there is a %package directive:
</P>
<!-- CODE SNIP //-->
<PRE>
%package bar
</PRE>
<!-- END CODE SNIP //-->
<P>This would result in the name of the subpackage being
foo-bar.
</P>
<P>In this way, it's easy to see the relationship of the subpackage to the main package (or to
other subpackages, for that matter). Of course, this naming convention might not be appropriate
in every case. So there is an option to the
%package directive for just this circumstance.
</P>
<H4><A NAME="ch18_ 8">
18.4.1.2. Adding -n to the %package Directive
</A></H4>
<P>The -n option is used to change the final name of a subpackage from
mainpackage-subpackage to subpackage. Let's modify the
%package directive in our earlier example to be
</P>
<!-- CODE SNIP //-->
<PRE>
%package -n bar
</PRE>
<!-- END CODE SNIP //-->
<P>The result is that the subpackage name would be
bar instead of foo-bar.
</P>
<H4><A NAME="ch18_ 9">
18.4.1.3. Updating Our Spec File
</A></H4>
<P>Let's apply some of our newly found knowledge to the spec file we're writing. Here's the list
of subpackages we need to create:
</P>
<UL>
<LI> The server
subpackage, to be called foo-server
<LI> The client subpackage, to be called
foo-client
<LI> The
baz development library subpackage, to be called bazlib
</UL>
<P>Since our package name is foo, and since the
%package directive creates subpackage names by prepending the package name, the
%package directives for the foo-server and
foo-client subpackages would be written as
</P>
<!-- CODE SNIP //-->
<PRE>
%package server
</PRE>
<!-- END CODE SNIP //-->
<P>and
</P>
<!-- CODE SNIP //-->
<PRE>
%package client
</PRE>
<!-- END CODE SNIP //-->
<P><CENTER>
<a href="../ch17/0245-0246.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0251-0254.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -