📄 appendix-a.html
字号:
<HTML>
<HEAD>
<TITLE>Maximum RPM (RPM):appendix-a: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=appendix-a //-->
<!-- PAGES=0337-0352 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="ch21/0334-0336.html">Previous</a> | <a href="ewtoc.html">Table of Contents</a> | <a href="appendix-b.html">Next</a></CENTER></P>
<A NAME="PAGENUM-337"><P>Page 337</P></A>
<H3><A NAME="1054_ 1">
Appendix A</a></H3>
<H2>
The Format of the<BR>
RPM File
</H2>
<A NAME="PAGENUM-338"><P>Page 338</P></A>
<H3>
A.1. The RPM File-Naming Convention
</H3>
<P>Although RPM will run just as well if a package file has been renamed, when the packages
are created during RPM's build process, they follow this specific naming convention:
</p>
<!-- CODE SNIP //-->
<PRE>
name-version-release.architecture.rpm
</PRE>
<!-- END CODE SNIP //-->
<P>In this convention</P>
<UL>
<LI> name is a name describing the packaged software.
<LI> version is the version of the packaged software.
<LI> release is the number of times this version of the software has been packaged.
<LI> architecture is a shorthand name describing the type of computer hardware the
packaged software is meant to run on. It may also be the string src, or nosrc. Both of
these strings indicate that the file is an RPM source package. The nosrc string means
that the file contains only package building files, while the src string means that the
file contains the necessary package building files and the software's source code.
</UL>
<P>A few notes are in order. Normally, the package name is taken verbatim from the
packaged software's name. Occasionally, this approach won't work—usually this occurs when the
software is split into multiple subpackages, each supporting a different set of functions. An <BR>
example of this situation is the way ncurses was packaged on Red Hat Linux. The
package incorporating the ncurses basic functionality was called
ncurses, while the package incorporating those parts of
ncurses's program development functionality was named
ncurses-devel.
</P>
<P>The version number is normally taken verbatim from the package's version. The only
restriction placed on the version is that it cannot contain a dash (-).
</P>
<P>The release can be thought of as the package's version. Traditionally it is a number, starting
at 1, that shows how many times the packaged software, at a given version, has been built.
This is tradition and not a restriction, however. As with the version number, the only restriction
is that dashes are not allowed.
</P>
<P>The architecture specifier is a string that indicates what hardware the package has been
built for. There are a number of architectures defined:
</P>
<UL>
<LI> i386—The Intel x86 family of microprocessors, starting with the 80386
<LI> alpha—The Digital Alpha/AXP series of microprocessors
<LI> sparc—Sun Microsystem's SPARC series of chips
<LI> mips—MIPS Technologies' processors
<LI> ppc—The Power PC microprocessor family
<LI> m68k—Motorola's 68000 series of CISC microprocessors
<LI> SGI—Equivalent to MIPS
</UL>
<A NAME="PAGENUM-339"><P>Page 339</P></A>
<P>This list will almost certainly change. For the most up-to-date list, refer to the file
/usr/lib/rpmrc. It contains information used internally by RPM, including a list of architectures
and equivalent code numbers.
</P>
<H3>
A.2. The RPM File Format
</H3>
<P>While the following details concerning the actual format of an RPM package file were
accurate at the time this was written, three points should be kept in mind:
</P>
<UL>
<LI> The file format is subject to change.
<LI> If a package file is to be manipulated somehow, you are strongly urged to use
the appropriate rpmlib routines to access the package file. Why? See the previous point!
<LI> This appendix describes the most recent version of the RPM file format: version
3. The file(1) utility can be used to see a package's file
format version.
</UL>
<P>With those caveats out of the way, let's take a look inside an RPM file…
</P>
<H4>
A.2.1. Parts of an RPM File
</H4>
<P>Every RPM package file can be divided into four distinct sections:
</P>
<UL>
<LI> The lead
<LI> The signature
<LI> The header
<LI> The archive
</UL>
<P>Package files are written to disk in network byte order. If required, RPM will
automatically convert to host byte order when the package file is read. Let's take a look at each section,
starting with the lead.
</P>
<B>A.2.1.1. The Lead
</B>
<P>The lead is the first part of an RPM package file. In previous versions of RPM, it was used
to store information used internally by RPM. Today, however, the lead's sole purpose is to
make it easy to identify an RPM package file. For example, the
file(1) command uses the lead. (Refer to section A.4 for a discussion on identifying RPM package files with the
file command.) All the information contained in the lead has been duplicated or superseded by information
contained in the header. (The header is discussed in section A.2.1.3.)
</P>
<P>RPM defines a C structure that describes the lead:
</P>
<!-- CODE SNIP //-->
<PRE>
struct rpmlead {
unsigned char magic[4];
unsigned char major, minor;
</PRE>
<!-- END CODE SNIP //-->
<A NAME="PAGENUM-340"><P>Page 340</P></A>
<!-- CODE //-->
<PRE>
short type;
short archnum;
char name[66];
short osnum;
short signature_type;
char reserved[16];
} ;
</PRE>
<!-- END CODE //-->
<P>Let's take a look at an actual package file and examine the various pieces of data that make
up the lead. In the following display, the number to the left of the colon is the byte offset, in
hexadecimal, from the start of the file. The eight groups of four characters show the hex value of
the bytes in the file—2 bytes per group of four characters. Finally, the characters on the right
show the ASCII values of the data bytes. When a data byte's value results in a non-printable
character, a dot (.) is inserted instead. Here are the first 32 bytes of a package file—in this case,
the package file rpm-2.2.1-1.i386.rpm:
</P>
<!-- CODE SNIP //-->
<PRE>
00000000: edab eedb 0300 0000 0001 7270 6d2d 322e ..........rpm-2.
00000010: 322e 312d 3100 0000 0000 0000 0000 0000 2.1-1...........
</PRE>
<!-- END CODE SNIP //-->
<P>The first 4 bytes (edab eedb) are the magic values that identify the file as an RPM package
file. Both the file command and RPM use these magic numbers to determine whether a file
is legitimate.
</P>
<P>The next 2 bytes (0300) indicate the RPM file format version. In this case, the file's major
version number is 3, and the minor version number is 0. Versions of RPM later than 2.1
create version 3.0 package files.
</P>
<P>The next 2 bytes (0000) determine what type of RPM file the file is. There are presently
two types defined:
</P>
<UL>
<LI> Binary package file (type=0000)
<LI> Source package file (type=0001)
</UL>
<P>In this case, the file is a binary package file.
</P>
<P>The next 2 bytes (0001) are used to store the architecture that the package was built for. In
this case, the number 1 refers to the i386 architecture. (Note that the architecture used
internally by RPM is actually stored in the header. This value is strictly for
file(1)'s use.) In the case of a source package file, these two bytes should be ignored, as source packages are not built for
a specific architecture.
</P>
<P>The next 66 bytes (starting with 7270 6d2d) contain the name of the package. The name
must end with a null byte, which leaves 65 bytes for RPM's usual
name-version-release_style name. In this case, we can read the name from the right side of the output:
</P>
<!-- CODE SNIP //-->
<PRE>
rpm-2.2.1-1
</PRE>
<!-- END CODE SNIP //-->
<P>Since the name rpm-2.2.1-1 is shorter than the 65 bytes allocated for the name, the
leftover bytes are filled with nulls.
</P>
<A NAME="PAGENUM-341"><P>Page 341</P></A>
<P>Skipping past the space allocated for the name, we see 2 bytes (0001):
</P>
<!-- CODE SNIP //-->
<PRE>
00000040: 0000 0000 0000 0000 0000 0000 0001 0005 ................
00000050: 0400 0000 24e1 ffbf 6bb3 0008 00e6 ffbf ....$...k.......
</PRE>
<!-- END CODE SNIP //-->
<P>These bytes represent the operating system for which this package was built. In this case,
1 equals Linux. As with the architecture-to-number translations, the operating system and
corresponding code numbers can be found in the file, /usr/lib/rpmrc.
</P>
<P>The next two bytes (0005) indicate the type of signature used in the file. A type 5 signature
is new to version 3 RPM files. The signature appears next in the file, but we need to discuss
an additional detail before exploring the signature.
</P>
<B>A.2.1.1.1. Wanted: A New RPM Data Structure</B>
<P>By looking at the C structure that defines the lead, and matching it with the bytes in an
actual package file, it's trivial to extract the data from the lead. From a programming standpoint,
it's also easy to manipulate data in the lead; it's simply a matter of using the element names
from the structure. But there's a problem. And because of that problem, the lead is no longer
used internally by RPM.
</P>
<B>A.2.1.1.1.1. The Lead: An Abandoned Data Structure</B>
<P>What's the problem, and why is the lead no longer used by RPM? The answer to these
questions is a single word: inflexibility. The technique of defining a C structure to access data in
a file just isn't very flexible. Let's look at an example.
</P>
<P>Flip back to the lead's C structure on page 349. Say, for example, that some software
comes along, and it has a long name. A very long name. A name so long, in fact, that the 66
bytes defined in the structure element name just couldn't hold it.
</P>
<P>What can we do? Well, we could certainly change the structure such that the
name element would be 100 bytes long. But once a new version of RPM is created using this new
structure, we have two problems:
</P>
<UL>
<LI> Any package file created
with the new version of RPM wouldn't be able to read
older package formats.
<LI> Any older version of RPM would be unable to install packages created with the
newer version of RPM.
</UL>
<P>Not a very good situation! Ideally, we would like to somehow eliminate the requirement
that the format of the data written to a package file be engraved in granite. We should be able to
do the following things, all without losing compatibility with existing versions of RPM:
</P>
<UL>
<LI> Add extra data to the file format
<LI> Change the size of existing data
<LI> Reorder the data
</UL>
<P>Sounds like a big problem, but there's a solution.</P>
<A NAME="PAGENUM-342"><P>Page 342</P></A>
<B>A.2.1.1.1.1.1. Is There a Solution?</B>
<P>The solution is to standardize the method by which information is retrieved from a file.
This is done by creating a well-defined data structure that contains easily searched information
about the data, and then physically separating that information from the data.
</P>
<P>When the data is required, it is found by using the easily searched information, which
points to the data itself. The benefits are that the data can be placed anywhere in the file, and that
the format of the data itself can change.
</P>
<B>A.2.1.1.1.1.2. The Solution: The Header Structure</B>
<P>The header structure is RPM's solution to the problem of easily manipulating information
in a standard way. The header structure's sole purpose in life is to contain zero or more pieces
of data. A file can have more than one header structure in it. In fact, an RPM package file
has two—the signature and the header. It was from this header that the header structure got
its name.
</P>
<P>There are three sections to each header structure. The first section is known as
the header structure header. The header structure header is used to identify the start of a header structure,
its size, and the number of data items it contains.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -