-->

Previous | Table of Contents | Next

Page 13

1.4.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:

Although these labels look like they have very little in common, in fact they both follow RPM's package labeling convention. There are three different components in every package label. Let's look at each one in order.

1.4.1.1. Component 1: The Software's Name

Every package label begins with the name of the software. The name might be derived from the name of the application packaged, or it might be a name describing a group of related programs bundled together by the package builder. The software names in the examples shown previously are nls and perl. As you can see, the software name is separated from the rest of the package label by a dash.

1.4.1.2. 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 the package builder's 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. The versions shown are 1.0 and 5.001m. A dash separates the software version from the remainder of the package label.

1.4.1.3. 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 of 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 are 1 and 4.

1.4.2. 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.

Page 14

However, a package file may be renamed, and the new filename won't confuse RPM in the least because the package label is contained within the file. For a fairly technical view of the inside of a package file, see Appendix A.

1.4.3. Packagewide Information

Some of the information contained in a package is general in nature. This information includes such items as


NOTE
For more information on RPM's signature checking capability, refer to section 7.1 in Chapter 7, "Using RPM to Verify Package Files."

1.4.4. Per-File Information

Each package also contains information about every file contained in the package. The information includes


NOTE
We'll discuss MD5 checksums in greater detail in section 6.1 of Chapter 6, "Using RPM to Verify Installed Packages."

Page 15

1.5. Summary

So a package management system uses the computer to keep track of all the various bits and pieces that comprise an application or an entire operating system. Most package management systems use a specially formatted file to keep everything together in a single, easily manageable entity, or package. Additionally, package management systems tend to provide one or more of the following functions:

RPM has been designed with Red Hat Software's past package management experiences in mind. PM and RPP provided most of these functions with varying degrees of success. Ewing and Troan have worked hard to make RPM better than its predecessors in every way. Now it's time to see how they did it and learn how to use RPM!

Page 16



Previous | Table of Contents | Next