📄 0215-0218.html
字号:
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):Making a Relocatable Package: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=15 //-->
<!-- PAGES=0215-0224 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch14/0212-0214.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0219-0221.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-215"><P>Page 215</P></A>
<H3><A NAME="ch15_ 1">
Chapter 15
</A></H3>
<H2>
Making a Relocatable<BR> Package
</H2>
<A NAME="PAGENUM-216"><P>Page 216</P></A>
<P>RPM has the capability to give users some latitude in deciding where packages are to be
installed on their systems. However, package builders must first design their packages to
give users this freedom.
</P>
<P>That's all well and good, but why would the ability to relocate a package be all that important?
</P>
<H3><A NAME="ch15_ 2">
15.1. Why Relocatable Packages?
</A></H3>
<P>One of the many problems that plague a system administrator's life is disk space. Usually,
there's not enough of it, and if there is enough, chances are it's in the wrong place. Here's a
hypothetical example:
</P>
<UL>
<LI> Some new software comes out and is desired greatly by the user community.
<LI> The system administrator carefully reviews the software's installation
documentation prior to doing the installation. (Hey, we
said it was hypothetical!) She notes that the software, all 150MB of it, installs into
/opt.
<LI> Frowning, the sysadmin fires off a quick
df command:
<!-- CODE //-->
<PRE>
# df
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda0 100118 28434 66514 30% /
/dev/sda6 991995 365527 575218 39% /usr
#
</PRE>
<!-- END CODE //-->
<P> Bottom line: There's no way 150MB of new software is going to fit on the
root filesystem.
</P>
<LI> Sighing heavily, the sysadmin ponders what to do next. If only there were some way
to install the software somewhere on the /usr filesystem.
</UL>
<P>It doesn't have to be this way. RPM has the ability to make packages that can be installed
with a user-specified prefix that dictates where the software will actually be placed. By making
packages relocatable, the package builder can make life easier for sysadmins everywhere. But
what exactly is a relocatable package?
</P>
<P>A relocatable package is a package that is standard in every way, save one. When a prefix tag
is added to a spec file, RPM will attempt to build a relocatable package.
</P>
<P>Note the word attempt. A few conditions must be met before a relocatable package can be
built successfully, and this chapter covers them all. But first, let's look at exactly how RPM can
relocate a package.
</P>
<H3><A NAME="ch15_ 3">
15.2. The prefix tag: Relocation Central
</A></H3>
<P>The best way to explain how the prefix tag is used is to step through an example. Here's
a sample prefix tag:
</P>
<!-- CODE SNIP //-->
<PRE>
Prefix: /opt
</PRE>
<!-- END CODE SNIP //-->
<A NAME="PAGENUM-217"><P>Page 217</P></A>
<P>In this example, the prefix path is defined as
/opt. This means that, by default, the package will install its files under
/opt. Let's assume that the spec file contains the following line in
its %files list:
</P>
<!-- CODE SNIP //-->
<PRE>
/opt/bin/baz
</PRE>
<!-- END CODE SNIP //-->
<P>If the package is installed without any relocation, this file will be installed in
/opt/bin. This is identical to how a nonrelocatable package is installed.
</P>
<P>However, if the package is to be relocated on installation, the path of every file in the
%files list is modified according to the following steps:
<OL>
<LI> The part of the file's path that corresponds to the path specified on the
prefix tag line is removed.
<LI> The user-specified relocation prefix is prepended to the file's path.
</OL>
<P>Using our /opt/bin/baz file as an example, let's assume that the user installing the
package wishes to override the default prefix
(/opt) with a new prefix, say /usr/local/opt.
Following the previous steps, we first remove the original prefix from the file's path:
</P>
<!-- CODE SNIP //-->
<PRE>
/opt/bin/baz becomes /bin/baz
</PRE>
<!-- END CODE SNIP //-->
<P>Next, we add the user-specified prefix to the front of the remaining part of the filename:
</P>
<!-- CODE SNIP //-->
<PRE>
/usr/local/opt + /bin/baz = /usr/local/opt/bin/baz
</PRE>
<!-- END CODE SNIP //-->
<P>Now that the file's new path has been created, RPM installs the file normally. This part of
it seems simple enough, and it is. But as mentioned earlier, there are a few things the
package builder needs to consider before getting on the relocatable package bandwagon.
</P>
<H3>
15.3. Relocatable Wrinkles: Things to Consider
</H3>
<P>While it's certainly no problem to add a prefix tag line to a spec file, it's necessary to
consider a few other issues:
</P>
<UL>
<LI> Every file in the
%files list must start with the path specified on the
prefix tag line.
<LI> The
software must be written such that it can operate properly if relocated.
Absolute symlinks are a prime example of this.
<LI> Other software must not rely on the relocatable package being installed in
any particular location.
</UL>
<P>Let's cover each of these issues, starting with the
%files list.
</P>
<A NAME="PAGENUM-218"><P>Page 218</P></A>
<H4><A NAME="ch15_ 4">
15.3.1. %files List Restrictions
</A></H4>
<P>As mentioned earlier, each file in the %files list must start with the relocation prefix. If
this isn't done, the build will fail:
</P>
<!-- CODE //-->
<PRE>
# rpm -ba cdplayer-1.0.spec
* Package: cdplayer
+ umask 022
+ echo Executing: %prep
...
Binary Packaging: cdplayer-1.0-1
Package Prefix = usr/local
File doesn't match prefix (usr/local): /usr/doc/cdplayer-1.0-1
File not found: /usr/doc/cdplayer-1.0-1
Build failed.
#
</PRE>
<!-- END CODE //-->
<P>In our example, the build proceeded normally until the time came to create the binary
package file. At that point RPM detected the problem. The error message says it all: The prefix line
in the spec file (/usr/local) was not present in the first part of the file's path
(/usr/doc/<BR>
cdplayer-1.0-1). This stopped the build in its tracks.
</P>
<P>The fact that every file in a relocatable package must be installed under the directory
specified in the prefix line raises some issues. For example, what about a program that reads a
configuration file normally kept in /etc? This question leads right into our next section.
</P>
<H4><A NAME="ch15_ 5">
15.3.2. Relocatable Packages Must Contain Relocatable Software
</A></H4>
<P>While this section's title seems pretty obvious, it's not always easy to tell if a particular piece
of software can be relocated. Let's take a look at the question raised at the end of the
previous section. If a program has been written to read its configuration file from
/etc, there are three possible approaches to making that program relocatable:
</P>
<UL>
<LI> Set the prefix to
/etc and package everything under /etc.
<LI> Package everything somewhere other than
/etc and leave out the config file entirely.
<LI> Modify
the program.
</UL>
<P>The first approach would certainly work from a purely technical standpoint, but not
many people would be happy with a program that installed itself in
/etc. So this approach isn't viable.
</P>
<P>The second approach might be more appropriate, but it forces users to complete the install
by having them create the config file themselves. If RPM's goal is to make software easier to
install and remove, this is not a viable approach either!
</P>
<P>The final approach might be the best. Once the program is installed, when the rewritten
software is first run, it can see that no configuration file exists in
/etc and create one. However, even though this would work, when the time came to erase the package, the config file
would be left behind. RPM had never installed it, so RPM couldn't get rid of it. There's also the
fact that this approach is probably more labor intensive than most package builders would like.
</P>
<P><CENTER>
<a href="../ch14/0212-0214.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0219-0221.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -