📄 0010-0012.html
字号:
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):An Introduction to Package Management: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=01 //-->
<!-- PAGES=0001-0016 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0007-0009.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0013-0016.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-10"><P>Page 10</P></A>
<UL>
<LI> Ease of rebuilding large numbers of packages. By making it easy for people who
were trying to create a Linux distribution consisting of several hundred packages, RPM
was a step in the right direction.
<LI> Ease of use. Many of the concepts used in RPP had withstood the test of time
and were used in RPM. For instance, the ability to verify the installation of a package
was one of the features that set RPP apart. It was adapted and expanded in RPM version 1.
</UL>
<P>But RPM version 1 wasn't perfect. There were a number of flaws, some of them major:
</P>
<UL>
<LI> It was slow. While the
use of Perl made RPM's development proceed more quickly,
it also meant that RPM wouldn't run as quickly as it would have had it been written in C.
<LI> Its database design was fragile. Unfortunately, under RPM version 1 it was
not unusual for there to be problems with the database. While dedicating a database
to package management was a good idea, the implementation used in RPM version 1
left a lot to be desired.
<LI> It was big. This is another artifact of using Perl. Normally, RPM's size
requirements were not an issue, except in one area. When performing an initial system
installation, RPM was run from a small, floppy-based system
environment. The need to have Perl available meant that space on the boot floppies was always a problem.
<LI> It didn't support multiple architectures (different types of computers) well. The
need to have a package manager support more than one type of computer hadn't
been acknowledged before. With RPM version 1, an initial
stab was taken at the problem, but the implementation
was incomplete. Nonetheless, RPM had been ported to
a number of other computer systems. It was becoming obvious that the issue
of multiarchitecture support was not going away and had to be addressed.
<LI> The package file
format wasn't extensible. This made it very difficult to add
functionality since any change to the file format would cause older versions of RPM to break.
</UL>
<P>Even though their Linux distribution was a success, and RPM was much of the reason for
it, Ewing and Troan knew that some changes were going to be necessary to carry RPM to the next level.
</P>
<B>
1.2.1.5. The RPM of Today: Version 2
</B>
<P>Looking back on their experiences with RPM version 1, Ewing and Troan made a major
change to RPM's design: They rewrote it entirely in C. This did wonderful things to RPM's speed
and size. Querying the database was quicker now, and there was no need to have Perl around
just to do package management.
</P>
<P>In addition, the database format was redesigned to improve both performance and
reliability. Displaying package information can take as little as a tenth of the time spent in RPM
version 1, for example.
</P>
<A NAME="PAGENUM-11"><P>Page 11</P></A>
<P>Realizing RPM's potential in the non-Linux arena, Ewing and Troan also created
rpmlib, a library of RPM routines that allow the use of RPM functionality in other programs.
RPM's ability to function on more than one architecture was also enhanced. Finally, the package
file format was made more extensible, clearing the way for future enhancements to RPM.
</P>
<P>So is RPM perfect? No program can ever reach perfection, and RPM is no exception. But as
a package manager that can run on several different types of systems, RPM has a lot to offer, and it will only get better. Let's take a look at the design criteria that drove the development of RPM.
</P>
<H3><A NAME="ch01_ 7">
1.3. RPM Design Goals
</A></H3>
<P>The design goals of RPM could best be summed up with the phrase "something for
everyone." While the main reason for the existence of RPM was to make it easier for Red Hat Software
to build the several hundred packages that comprised the Linux distribution, it was not the
only reason RPM was created. The following sections take a look at the various requirements
the Red Hat team used in its design of RPM.
</P>
<H4><A NAME="ch01_ 8">
1.3.1. Making It Easy to Get Packages on and off the System
</A></H4>
<P>As you've learned in this chapter, the act of installing a package can involve many
complex steps. Entrusting these steps to a person who may not have the necessary experience is a
strategy for failure. So the goal for RPM was to make it as easy as possible for anyone to install
and uninstall packages. These are complex and error-prone operations, which RPM should
handle for the user.
</P>
<P>The other side of this issue is that RPM should give the package builder almost total control
in terms of how the package is installed. The reason for this is simple: If the package builders
do their homework, their packages should install and uninstall properly.
</P>
<H4><A NAME="ch01_ 9">
1.3.2. Making It Easy to Verify That a Package Was <BR>
Installed Correctly
</A></H4>
<P>Because software problems are a fact of life, the ability to verify the proper installation of
a package is vital. If done properly, it should be possible to catch a variety of problems, including things such as missing or modified files.
</P>
<H4><A NAME="ch01_ 10">
1.3.3. Making It Easy for the Package Builder
</A></H4>
<P>Although we're dedicating an entire book to package management, it really should be a
small portion of the package builder's job. Why? He's got better things to do! If the package
builders are the people who are actually creating the software to be packaged, that's where they
should be spending the majority of their time.
</P>
<A NAME="PAGENUM-12"><P>Page 12</P></A>
<P>Even if the package builder isn't actually writing software, he still has better things to do
than worry about building packages. For instance, he might be responsible for building many
packages. The less time spent on building an individual package, the more packages that can be built.
</P>
<H4><A NAME="ch01_ 11">
1.3.4. Making It Start with the Original Source Code
</A></H4>
<P>It was deemed important that RPM start with the original, unmodified source code. Why is this so important?
</P>
<P>Using the original sources makes it possible to separate the changes required to build the
package from any changes implemented to fix bugs, add new features, or anything else. This is
a good thing for package builders because many of them are not the original authors of the programs they package.
</P>
<P>This separation makes it easy, months down the road, to know exactly what changes were
made in order to get the package to build. This is important when a new version of the
packaged software becomes available. Many times it's only necessary to apply the original package
building changes to the newer software. At worst, the changes provide a starting point to
determine what sorts of things might need to be changed in the new version.
</P>
<H4><A NAME="ch01_ 12">
1.3.5. Making It Work on Different Computer Architectures
</A></H4>
<P>One of the tougher things for a package builder to do is to take a program, make it run
on more than one type of computer, and distribute packages for each. Because RPM makes it
easy to use a program's original source code, add the changes necessary to get it to build, and
produce a package for each architecture in one step, it can be pretty handy.
</P>
<H3><A NAME="ch01_ 13">
1.4. What's in a Package?
</A></H3>
<P>With all the magical things we've claimed that package management software in general
(and RPM in particular) can do, you'd think there was a tiny computer guru bundled in every
package. However, the reality is not that magical. The following sections give a quick overview
of the more important parts of an RPM package.
</P>
<BR>
<P>
<CENTER>
<TABLE BGCOLOR="#FFFF99">
<TR><TD><B>
NOTE
</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
See Appendix A, "The Format of the RPM File, " for complete details on
the contents of an .rpm file.
</BLOCKQUOTE></TD></TR>
</TABLE></CENTER>
</P>
<P><CENTER>
<a href="0007-0009.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0013-0016.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -