0111-0116.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 258 行
HTML
258 行
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):The Philosophy Behind 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=09 //-->
<!-- PAGES=0111-0118 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="../ch08/0108-0110.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0117-0118.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-111"><P>Page 111</P></A>
<H3><A NAME="1054_ 0">
Part II</A></H3>
<H2>
RPM and Developers: How to Distribute <BR>
Your Software More <BR>
Easily with RPM
</H2>
<A NAME="PAGENUM-112"><P>Page 112</P></A>
<A NAME="PAGENUM-113"><P>Page 113</P></A>
<H2>
<A NAME="ch09_ 1">
Chapter 9<br>The Philosophy <BR>Behind RPM
</A>
</H2>
<A NAME="PAGENUM-114"><P>Page 114</P></A>
<P>As you saw in Part I, "RPM and Computer Users: How to Use RPM to Effectively
Manage Your Computer," RPM can make life much easier for the user. With automated installs,
upgrades, and erasures, RPM can take a lot of the guesswork out of keeping a computer
system up-to-date.
</P>
<P>But what about people who sling code for a living? Does RPM have anything to offer
them? Yes! One of the best things about RPM is that although it was designed to make life easier
for users, it was written by people who would be using it to build many packages. So the
design philosophy of RPM has a definite bias toward making life easier for developers. The
following sections list some of the reasons you should consider building packages with RPM.
</P>
<H4><A NAME="ch09_ 2">
9.1. Pristine Sources
</A></H4>
<P>Although many developers might use RPM to package their own software, just as many, if
not more, are going to be packaging software that they have not written. Therefore, there are
some aspects to RPM's design that are geared toward third-party package builders. One such
aspect is RPM's use of pristine sources.
</P>
<P>When a third-party package builder decides to package someone else's software, he often
gets the software from the Net, normally as a tar file compressed with something like GNU
zip. That's probably about the only generalization we can make when talking about software
that is eligible for packaging. Once we look inside the
tar file, there is a world of possible differences:
</P>
<UL>
<LI> The
application could be available in pure source form, in pure binary form, or
some combination of both.
<LI> The application might have been written to be built using
make, imake, or a script included with the sources. Or, it might have to be built entirely by hand.
<LI> The application might need to be configured prior to use. Maybe it uses GNU configure, a custom configuration script, or one or more files that need to be edited to reflect the target environment.
<LI> The application might have been written to reside in specific directories, and those directories do not exist, or are not appropriate on the target system.
<LI> The application might not even support the target environment, requiring all
manner of changes to port it to the target environment.
</UL>
<P>We could go on, but you probably get the idea. It's a rare application that comes off the
Net ready to package, and the changes required vary widely. What to do?
</P>
<P>This is where the concept of pristine sources comes in. RPM is designed to use the sources
as they come from the application's developer, no matter how it has been packaged and configured. The main benefit is that the changes you as a package builder need to make remain
separate from the original sources, in a distinct collection of patches.
</P>
<A NAME="PAGENUM-115"><P>Page 115</P></A>
<P>This may not sound like much of an advantage, but consider how this would work if a
new version of the application came out. If the new version had a few localized
bug fixes, it's entirely possible that the original patches could be applied and a new package built, with a
single RPM command. Even if the patches didn't apply cleanly, it would
at least give an indication as to what might need to be done to get the new version built and packaged.
</P>
<P>If your users sometimes customize packages, having pristine sources makes it easier for
them, too. They can see what patches you've created and can easily add their own.
</P>
<P>Another benefit to using pristine sources is that it makes keeping track of multiple versions
of a package simple. Instead of keeping patched sources around, or battling a revision control system, it's only necessary to keep the following:
</P>
<UL>
<LI> The original sources in their tar file
<LI> A copy of the patches you applied to get the application to build
<LI> A file used by RPM to control the package-building process
</UL>
<P>With these three items, it's possible to easily build the package at any time. Keeping track
of multiple versions only entails keeping track of each version of these three components,
rather than hundreds or thousands of patched source files.
</P>
<P>In fact, it gets better than that. RPM can also build a source package containing these
three components. The source package, named using RPM's standard naming convention,
keeps everything you need to re-create a specific version of a package in one uniquely named
file. Keeping track of multiple versions of multiple packages is simply a matter of keeping the
appropriate source packages around. Everything else can be built from them.
</P>
<H4><A NAME="ch09_ 3">
9.2. Easy Builds
</A></H4>
<P>RPM makes it easy to build packages. Just as with the use of pristine sources, the fact that
the build process is simple is an even greater advantage to the third-party package builders
responsible for many packages than it is to a one-package software development house. But in
either case, RPM's ease of building is a welcome relief. The following sections document some of
the ways that RPM makes building packages a straightforward process.
</P>
<H4><A NAME="ch09_ 4">
9.2.1. Reproducible Builds
</A></H4>
<P>One of the biggest problems facing developers is reproducing a particular build. This
problem is the main reason so much effort is put into creating and deploying version control systems
to manage sources.
</P>
<P>Although RPM cannot compete with a full-blown revision control system, it does an
excellent job of keeping in one place everything required to build a particular version of a package.
Remember the source package mentioned earlier? With one command, RPM can open
the
</P>
<A NAME="PAGENUM-116"><P>Page 116</P></A>
<P>
package, extract the sources, patch them, perform a build, and create a new binary
package, ready for your users. The best part is that the binary package will be the same every time
you build it because everything needed to create it is kept in one source package.</P>
<H4><A NAME="ch09_ 5">
9.2.2. Unattended Builds
</A></H4>
<P>As mentioned earlier, completely building a package takes only one RPM command. This
makes it easy to set up automated build procedures that can build 100 packages as easily as 1.
Anything from a single package consisting of 1 application to the several hundred packages
that comprise an entire operating system can be built automatically using RPM.
</P>
<H4><A NAME="ch09_ 6">
9.3. Multiarchitecture/Operating System Support
</A></H4>
<P>It has always been a fact for software developers that their applications may need to be
ported to multiple operating systems. It is also becoming more common that a particular
operating system might run on several different platforms, or architectures.
</P>
<P>RPM's capability to support multiple architectures and operating systems makes it easy to
build the same package for many OS/platform combinations. A package might be configured to
build on only one architecture/OS combination, or on several. The only limitation is the application's portability.
</P>
<H4><A NAME="ch09_ 7">
9.4. Easier for Your Users
</A></H4>
<P>While we are primarily concerned with RPM's advantages from the developer's point of
view, it's worth looking at RPM from the user's standpoint for a moment. After all, if RPM
makes life easier for your users, that can translate into lower support costs.
</P>
<H4><A NAME="ch09_ 8">
9.4.1. Easy Upgrades
</A></H4>
<P>Probably the biggest headache for user and developer alike is the upgrade of an application,
or worse yet, an entire operating system! RPM can make upgrading a one-step process. With
one command, a new package can be installed, and the remnants of the old package removed.
</P>
<H4><A NAME="ch09_ 9">
9.4.2. Intelligent Configuration File Handling
</A></H4>
<P>Configuration files—nearly every application has them. They might go by different
names, but they all control the behavior of their application. Users normally customize config files
to their liking and would be upset if their customizations were lost during the installation,
upgrade, or removal of a package.
</P>
<P><CENTER>
<a href="../ch08/0108-0110.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0117-0118.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?