Table of Contents
This chapter contains descriptions of various internal logical objects managed by LPMtool. This information is not strictly required in order to perform ordinary tasks, such as installing or uninstalling packages. However, this information includes important details of how LPMtool works behind the scenes, and is vital to understanding how package information is processed.
Not all LPMtool objects are described in this chapter. This chapter describes only the major LPMtool objects.
Each package is identified by a label that consists of four parts:
Name
Architecture
Version
Release
The package name should be the same
as the common name the software is known as.
The name of a package that contains the Linux kernel would be called
“kernel”.
A package that contains the Emacs editor would be called
“emacs”.
The package name is a simple word, possibly hyphenated.
The “architecture” designates the CPU
type that the package runs on, such as i686
or
x86_64
. Most packages for 32-bit Intel family-based Linux
distribution are compiled for the i386
CPU architecture.
LPMtool checks the configuration for the permitted architectures that may be
installed. LPMtool running on a typical Pentium-class machine allows the
installation of either
i386
and i686
packages (usually code
that's specifically optimized for a Pentium-class CPU), but does not allow
the installation of packages whose architecture is given as
x86_64
, because 64-bit code will obviously not run on a
32-bit Pentium. On the other hand, LPMtool running on an
x86_64
platform will accept x86_64
,
i386
, i686
, and several other
architectures.
The architecture label “noarch” applies to packages without any platform-specific contents, and which can be installed on any platform. An example would be a package that contains only documentation files, which can be installed and viewed on any platform.
The package name cannot contain control characters or spaces. The following punctuation characters are prohibited: “/()=<>!”. The name cannot begin or end with a hyphen, or contain two hyphens in a row.
The package version and release specify the package's “vintage”. The version is the publicly known version of the package. The version of a package that contains the Linux kernel 2.6.10 would obviously be “2.6.10”. The package release specifies a particular LPMtool edition of this version of the package.
For example, the initial release of the “kernel 2.6.10” package would be labeled as release “1”. Suppose that some kind of a packaging error was discovered later: some file or module was accidentally left out, for example. Or, there was an error in one of the configuration file. This is corrected by issuing another “kernel 2.6.10” package, labeled as release “2”. The next errata release will be release “3”, and so on.
This process is often used to issue emergency bug fixes. When a critical error is discovered in some software, a patch is often made available, that corrects the error, before the correct version of the package is issued. This results in a new package with an updated release number, but the same version, that includes the emergency bug fix.
The package version and release cannot contain control characters or spaces. The following punctuation characters are also prohibited: “-/=!<>()”.
LPMtool packages automatically have the name of the base system distribution, that they are built for, appended to each release version. For example, packages built for Fedora Core 1 have “.fc1” automatically appended to their release number. Example:
Release: 1
The resulting packages will actually carry a release number of “1.fc1”. This allows using the same specfile to build the same package for a newer base system distribution, and get binary packages with updated release numbers prepared automatically.
A NAVR is specified as “name(arch)-version-release”. Example: a package label with the name “foo”, architecture “i386”, version “1.0”, release “2.0” is specified as “foo(i386)-1.0-2.0”.
LPMtool often compares a package's version and release against another package of the same name and architecture. This usually occurs when searching a repository for updated packages.
A package is considered to be “newer” than another package (of the same name and architecture) if the package version compares “higher” than the other package version, or if both versions are the same but the package release compares “higher” than the other package release.
Different software packages follow different version conventions. The logic used for comparing package versions is designed to accomodate most reasonable version conventions (the same comparison logic is also used to compare releases). Package versions (and releases) are compared using the following rules:
Each version (or release) is decomposed into groups of consecutive letters and consecutive digits. All punctuation is ignored, except that it serves as a delimiter between groups of letters and numbers. For example: version “3.beta17” is broken down into three components: “3”, “beta”, and “17”.
The first component of both versions is compared against each other. If both components contain consecutive digits they are compared as numbers; naturally higher numbers are considered “higher”. If both components contain consecutive letters, they are compared in alphabetical order. Otherwise the alphabetical component is always considered to be “higher” that the numeric component.
If the first components compare as equal, then the second components of both versions are compared, and so on until one of the version's components compares higher than the other version's component. The corresponding version is then considered to be “higher” then the other version.
If all components of one version compare equal to the other version's component, but the other version has more components, then the other version is “higher”.
Observe that “3.beta17” compares equal to “3-beta17”. That's because punctuation's sole role is only to delimit groups of letters and numbers; the actual punctuation character is not relevant.