📄 0251-0254.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="0247-0250.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0255-0259.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-251"><P>Page 251</P></A>
<P>Since the baz library's package name is not to start with
foo, we need to use the -n option on its %package directive:
</P>
<!-- CODE SNIP //-->
<PRE>
%package -n bazlib
</PRE>
<!-- END CODE SNIP //-->
<P>Our requirements further state that foo-server and
foo-client are to have the same version as the main package.
</P>
<P>One of the time-saving aspects of using subpackages is that there is no need to duplicate
information for each subpackage if it is already defined in the main package. Therefore, since
the main package's preamble has a version tag defining the version as 2.7, the two
subpackages that lack a version tag in their preambles will simply inherit the main package's version
definition.
</P>
<P>Since the bazlib subpackage's preamble contains a
version tag, it must have its own unique version.
</P>
<P>In addition, each subpackage must have its own
summary tag.
</P>
<P>So, based on these requirements, our spec file now looks like this:
</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...
%package server
Summary: The foo server
%package client
Summary: The foo client
%package -n bazlib
Version: 5.6
Summary: The baz library
</PRE>
<!-- END CODE //-->
<P>We can see the subpackage structure starting to appear now.
</P>
<H4><A NAME="ch18_ 10">
18.4.1.4. Required Tags in Subpackages
</A></H4>
<P>There are a few more tags we should add to the subpackages in our sample spec file. In fact,
if these tags are not present, RPM will issue a most impressive warning:
</P>
<!-- CODE //-->
<PRE>
# rpm -ba foo-2.7.spec
Package: foo
Package: foo-server
Field must be present : Description
Field must be present : Group
</PRE>
<!-- END CODE //-->
<A NAME="PAGENUM-252"><P>Page 252</P></A>
<!-- CODE //-->
<PRE>
Package: foo-client
Field must be present : Description
Field must be present : Group
Package: bazlib
Field must be present : Description
Field must be present : Group
Spec file check failed!!
Tell rpm-list@redhat.com if this is incorrect.
#
</PRE>
<!-- END CODE //-->
<P>Our spec file is incomplete. The bottom line is that each subpackage
must have these three tags:
</P>
<UL>
<LI> The
%description tag
<LI> The
group tag
<LI> The
summary tag
</UL>
<P>It's easy to see that the first two tags are required, but what about
summary? Well, we lucked out on that one: We already included a
summary for each subpackage in our sample spec file.
</P>
<P>Let's take a look at the %description tag first.
</P>
<H4><A NAME="ch18_ 11">
18.4.1.5. The %description Tag
</A></H4>
<P>As you've probably noticed, the %description tag differs from other
tags. First of all, it starts with a percent sign, making it look similar to a directive. Second, its data can span
multiple lines. The third difference is that the
%description tag must include the name of the
subpackage it describes. This is done by appending the subpackage name to the
%description tag itself. So, given these %package directives:
</P>
<!-- CODE SNIP //-->
<PRE>
%package server
%package client
%package -n bazlib
</PRE>
<!-- END CODE SNIP //-->
<P>our %description tags would start with
</P>
<!-- CODE SNIP //-->
<PRE>
%description server
%description client
%description -n bazlib
</PRE>
<!-- END CODE SNIP //-->
<P>Notice that we've included the -n option in the
%description tag for bazlib. This was intentional, as it makes the name completely unambiguous.
</P>
<H4><A NAME="ch18_ 12">
18.4.1.6. Our Spec File So Far
</A></H4>
<P>Okay, let's take a look at the spec file after we've added the appropriate
%descriptions, along with group tags for each subpackage:
</P>
<!-- CODE SNIP //-->
<PRE>
Name: foo
Version: 2.7
Release: 1
</PRE>
<!-- END CODE SNIP //-->
<A NAME="PAGENUM-253"><P>Page 253</P></A>
<!-- CODE //-->
<PRE>
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...
%package server
Summary: The foo server
Group: bogus/junque
%description server
This is the long description for the foo server...
%package client
Summary: The foo client
Group: bogus/junque
%description client
This is the long description for the foo client...
%package -n bazlib
Version: 5.6
Summary: The baz library
Group: bogus/junque
%description -n bazlib
This is the long description for the bazlib...
</PRE>
<!-- END CODE //-->
<P>Let's take a look at what we've done. We've created a main preamble as we normally
would. We then created three additional preambles, each starting with a
%package directive. Finally, we added a few tags to the subpackage preambles.
</P>
<P>But what about version tags? Aren't the server and client subpackages missing them?
</P>
<P>Not really. Remember that if a subpackage is missing a given tag, it will inherit the value
of that tag from the main preamble. We're well on our way to having a complete spec file, but
we aren't quite there yet.
</P>
<P>Let's continue by looking at the next part of the spec file that changes when building subpackages.
</P>
<H4><A NAME="ch18_ 13">
18.4.2. The %files List
</A></H4>
<P>In an ordinary single-package spec file, the
%files list is used to determine which files are
actually going to be packaged. It is no different when building subpackages. What
is different is that there must be a %files list for each subpackage.
</P>
<P>Since each %files list must be associated with a particular
%package directive, we simply label each %files list with the name of the subpackage, as specified by each
%package directive. Going back to our example, our
%package lines were
</P>
<!-- CODE SNIP //-->
<PRE>
%package server
%package client
%package -n bazlib
</PRE>
<!-- END CODE SNIP //-->
<A NAME="PAGENUM-254"><P>Page 254</P></A>
<P>Therefore, our %files lists should start with
</P>
<!-- CODE SNIP //-->
<PRE>
%files server
%files client
%files -n bazlib
</PRE>
<!-- END CODE SNIP //-->
<P>In addition, we need the main package's %files list, which remains unnamed:
</P>
<!-- CODE SNIP //-->
<PRE>
%files
</PRE>
<!-- END CODE SNIP //-->
<P>The contents of each %files list is dictated entirely by the software's requirements. If, for
example, a certain file needs to be packaged in more than one package, it's perfectly all right
to include the filename in more than one list.
</P>
<H4><A NAME="ch18_ 14">
18.4.2.1. Controlling Packages with the %files List
</A></H4>
<P>The %files list wields considerable power over subpackages. It's even possible to prevent a
package from being created by using the %files list. But is there a reason you'd want to go to
the trouble of setting up subpackages, only to keep one from being created?
</P>
<P>Actually, there is. Take, for example, the case where client/server_based software is to be
packaged. Certainly, it makes sense to create two subpackages: one for the client and one for
the server. But what about the main package? Is there any need for it?
</P>
<P>Quite often there's no need for a main package. In those cases, removing the main
%files list entirely will result in no main package being built.
</P>
<H4><A NAME="ch18_ 15">
18.4.2.2. A Point Worth Noting
</A></H4>
<P>Keep in mind that an empty %files list (that is, a
%files list that contains no files) is not the same as not having a
%files list at all. As noted previously, entirely removing a
%files list results in RPM not creating that package. However, if RPM comes across a
%files list with no files, it will happily create an empty package file.
</P>
<P>This feature (which also works with subpackage
%files lists) comes in handy when used in concert with conditionals. If a
%files list is enclosed by a conditional, the package will be
created (or not) based on the evaluation of the conditional.
</P>
<H4><A NAME="ch18_ 16">
18.4.2.3. Our Spec File So Far
</A></H4>
<P>Okay, let's update our sample spec file. Here's what it looks like after adding each of
the subpackages' %files lists:
</P>
<!-- CODE SNIP //-->
<PRE>
Name: foo
Version: 2.7
Release: 1
Source: foo-2.7.tgz
CopyRight: probably not
</PRE>
<!-- END CODE SNIP //-->
<P><CENTER>
<a href="0247-0250.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0255-0259.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -