Maximum RPM (RPM):An Introduction to Package Management:EarthWeb Inc.-






-->
















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:



nls-1.0-1
perl-5.001m-4


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



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







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



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








NOTE



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




The file's contents


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:



Installing new packages
Removing old packages
Upgrading from an old package to a new one
Obtaining information about installed packages


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