| Maximum RPM: Taking the Red Hat Package Manager to the Limit | ||
|---|---|---|
| Prev | Chapter 1. An Introduction to Package Management | Next |
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] .
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-1
perl-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:
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.
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.
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.
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.
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]
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.
| [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. |