Chapter 13. LPMtool Objects

Table of Contents

1. NAVR - name, architecture, version, release
1.1. NAVR representation
1.2. Comparing package versions and releases
2. Resources
2.1. Required resources: /etc/passwd, /etc/group
2.2. Generic resources
3. Special logic for file-based resources
4. Dependencies
5. Resource Databases
5.1. Finding dependencies
6. Repositories
7. Packages
7.1. Binary package files
7.2. Source package files
7.3. The Package Manifest File
7.4. Metapackage files
8. Transactions
9. Transaction Lists
10. New Transaction Lists

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.

1. NAVR - name, architecture, version, release

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.

1.1. NAVR representation

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.

1.2. Comparing package versions and releases

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:

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

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

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

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