0119-0122.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 232 行
HTML
232 行
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):The Basics of Developing with RPM: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=10 //-->
<!-- PAGES=0119-0124 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch09/0117-0118.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0123-0124.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-119"><P>Page 119</P></A>
<H3><A NAME="ch10_ 1">
Chapter 10
</A></H3>
<H2>
The Basics of Developing<BR>
with RPM
</H2>
<A NAME="PAGENUM-120"><P>Page 120</P></A>
<P>Now that we've seen the design philosophy of RPM, let's look at the nuts and bolts of
RPM's build process. Building a package is similar to compiling code—there are inputs, an
engine that does the dirty work, and outputs.
</P>
<H4><A NAME="ch10_ 2">
10.1. The Inputs
</A></H4>
<P>There are three different kinds of inputs that are used to drive RPM's build process. Two
of the three inputs are required, and the third, strictly speaking, is optional. But unless
you're packaging your own code, chances are you'll need it.
</P>
<H4><A NAME="ch10_ 3">
10.1.1. The Sources
</A></H4>
<P>First and foremost are the sources. After all, without them, there wouldn't be much
to build! In the case of packaging someone else's software, the sources should be kept as the author
distributed them, which usually means a compressed
tar file. RPM can handle other archive formats, but a bit more up-front effort is required.
</P>
<P>In any case, you should not modify the sources used in the package building process. If
you're a third-party package builder, the sources should be just the way you got them from the
author's FTP site. If it's your own software, the choice is up to you, but you should consider
starting with your mainstream sources.
</P>
<H4><A NAME="ch10_ 4">
10.1.2. The Patches
</A></H4>
<P>Why all the emphasis on unmodified sources? Because RPM gives you the ability to
automatically apply patches to them. Usually, the nature of these patches falls into one of the
following categories:
</P>
<UL>
<LI> The patch addresses an issue specific to the target system. This could include
changing makefiles to install the application into the appropriate directories, or resolving
cross-platform conflicts, such as replacing BSD system calls with their SYSV counterparts.
<LI> The patch creates files that are normally created during a configuration step in
the installation process. Many times, it's necessary to edit either configuration files
or scripts in order to set things up for compilation. In other cases, a
configuration utility needs to be run before the sources are compiled. In either instance, the patches
create the environment required for proper compilation.
</UL>
<A NAME="PAGENUM-121"><P>Page 121</P></A>
<H4><A NAME="ch10_ 5">
10.1.2.1. Creating the Patches
</A></H4>
<P>While it might sound a bit daunting to take into account the types of patches outlined
here, it's really quite simple. Here's how it's done:
</P>
<OL>
<LI> Unpack the sources.
<LI> Rename the top-level directory. Make it end with .orig, for example.
<LI> Unpack the sources again, leaving the top-level directory name unchanged.
</OL>
<P>The source tree that you created the second time will be the one you'll use to get the software to build.
</P>
<P>If the software builds with no changes required, that's great—you won't need a patch. But
if you had to make any changes, you'll have to create a set of patches. To do so, simply clean
the source directory of any binaries. Then issue a recursive
diff command to compare the source tree you used for the build against the original, unmodified source tree.
It's as easy as that!
</P>
<H4><A NAME="ch10_ 6">
10.1.3. The Spec File
</A></H4>
<P>The spec file is at the heart of RPM's packaging building process. Similar in concept to a
makefile, it contains information required by RPM to build the package, as well as instructions
telling RPM how to build it. The spec file also dictates exactly what files are a part of the package
and where they should be installed.
</P>
<P>As you might imagine, with this many responsibilities, the spec file format can be a bit
complex. However, it's broken into several sections, making it easier to handle. All told, there
are eight sections:
</P>
<UL>
<LI> The preamble—The
preamble contains information that will be displayed when
users request information about the package. This includes a description of the
package's function, the version number of the software, and so on. Also contained in
the preamble are lines identifying sources, patches, and even an icon to be used if the package is manipulated by graphical interface.
<LI> The prep section—The prep section is where the actual work of building a
package starts. As the name implies, this section is where the necessary preparations are
made prior to the actual building of the software.
In general, if anything needs to be done to the sources prior to building the software, it needs to happen in the prep
section. Usually, this boils down to unpacking the sources.<BR>
The contents of this section are an ordinary shell script. However, RPM does
provide two macros to make life easier. One macro can unpack
a compressed tar file and cd into the source directory.
The other macro easily applies patches to the
unpacked sources.
</UL>
<A NAME="PAGENUM-122"><P>Page 122</P></A>
<UL>
<LI> The build
section—Like the prep section, the build section consists of a shell
script. As you might guess, this section is used to perform whatever commands are
required to actually compile the sources. This section could
consist of a single make command, or be more complex if the build process required it. Since most software today is
built using make, there are no macros available in this section.
<LI> The install section—Also containing a shell script, the install section is used
to perform the commands required to actually install the software.
If the software's author added an install target in the makefile, this section might only consist
of a make install command. Otherwise, you'd need to add the usual assortment of
cp, mv, or install commands to get the job done.
<LI> Install and uninstall scripts—Whereas
the previous sections contain either information required by RPM
to build the package or the actual commands to do the
deed, this section is different. It consists of scripts
that will be run on the user's system when the package is actually installed or removed. RPM can execute
a script in the following instances:
<UL>
<LI> Prior to the package
being installed
<LI> After the package has been installed
<LI> Prior to the package being erased
<LI> After the package has been erased
</UL>
<P> One example of when this capability would be required is when a package
contains shared libraries. In this case, ldconfig would need to be run after the package
is installed or erased. As another example, if a package
contains a shell, the file /etc/shells would need to be updated appropriately when the package was installed
or erased.<BR>
<LI> The verify
script—This is another script that is executed on the user's system. It
is executed when RPM verifies the package's proper installation. Although RPM
does most of the work verifying packages, this script can be used to verify aspects of
the package that are beyond RPM's capabilities.
<LI> The clean section—Another script that can be present is a script that can clean
things up after the build. This script is rarely used
because RPM normally does a good job of clean-up in most build environments.
<LI> The file list—The last section consists of a list of files that will comprise the
package. Additionally, a number of macros can be used to control file attributes when
installed, as well as to denote which files are documentation and which contain
configuration information. The file list is very important; if it is missing, no package will be built.
</UL>
<P><CENTER>
<a href="../ch09/0117-0118.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0123-0124.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?