Библиотека сайта rus-linux.net
| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 1. An Introduction to Package Management | Next |
What's in a package?
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. Here's a quick overview of the more important parts of an RPM package [1] .
RPM's Package Labels
Every package built for RPM has to have a specific set of information that uniquely identifies it. We call this information a package label. Here are two sample package labels:
nls-1.0-1perl-5.001m-4
While these labels look like they have very little in common, in fact they all follow RPM's package labelling convention. There are three different components in every package label. Let's look at each one in order:
Component #1: The Software's Name
Every package label begins with the name of the software. The name
may be derived from the name of the application packaged, or it may
be a name describing a group of related programs bundled together by
the package builder. The software names in the packages listed
above are: nls and perl.
As you can see, the software name is separated from the rest of the
package label by a dash.
Component #2: The Software's Version
Next in the package label is an identifier that describes the
version of the software being packaged. If the package builder
bundled a number of related programs together, the software version
is probably a number of their own choosing. However, if the package
consists of one major application, the software version normally
comes directly from the application's developer. The actual version
specification is quite flexible, as can be seen in the examples
above. The versions shown are: 1.0 and
5.001m. A dash separates the software version
from the remainder of the package label.
Component #3: The Package's Release
The package release is the most unambiguous part of a package label.
It is a number chosen by the package builder. It reflects the
number of times the package has been rebuilt using the same version
software. Normally, the rebuilds are due to bugs uncovered after
the package has been in use for a while. By tradition, the package
release starts at 1. The package releases in
the example above are: 1 and
4.
Labels And Names: Similar, But Distinct
Package labels are used internally by RPM. For example, if you ask RPM to list every installed package, it will respond with a list of package labels. When a package file is created, part of the filename consists of the package label. There is no technical requirement for this, but it does make it easier to keep track of things.
However, a package file may be renamed, and the new filename won't confuse RPM in the least. That's because the package label is contained within the file. For a fairly technical view of the inside of a package file, refer to Appendix A.
Package-wide Information
Some of the information contained in a package is general in nature. This information includes such items as:
The date and time the package was built.
A description of the package's contents.
The total size of all the files installed by the package.
Information that allows the package to be grouped with similar packages.
A digital "signature" that can be used to verify the authenticity and integrity of the package. [2]
Per-file Information
Each package also contains information about every file contained in the package. The information includes:
The name of every file and where it is to be installed.
Each file's permissions.
Each file's owner and group specifications.
The MD5 checksum of each file. [3]
The file's contents.
Notes
| [1] | See Appendix A for complete details on the contents of a .rpm file. |
| [2] | For more information on RPM's signature checking capability, refer to the section called rpm -K — What Does it Do? in Chapter 7. |
| [3] | We'll discuss MD5 checksums in greater detail in the section called MD5 Checksum in Chapter 6. |