7. Packages

All .lp package files (including source package files) follow the same basic structure. A .lp file contains chunks. The end of the first chunk is immediately followed by the start of a second chunk, and so on.

Every chunk has a name. Each chunk begins with a single byte that gives the number of characters in the chunk's name, followed by the name itself.

The contents of the chunk follow the name, and consist of one or more segments. Each segment starts with two bytes that give the number of bytes in the segment (high order byte first), followed by the corresponding number of bytes. The end of the chunk is marked by a segment whose byte count is given as zero.

Chunks that are less than 65536 bytes long consist of a single segment with the chunk's entire content, followed by a zero-byte count segment. Chunks with more that 65535 bytes of content consist of a one or more segments that are 65535 bytes long. If the chunk's length is not an even multiple of 65535, the remainder goes into the final, smaller segment, which is then followed by the terminating zero-byte segment.

The next chunk begins immediately after the terminating zero-byte segment.

A chunk's name defines what the chunk contains. The various chunks are described later. The following two special chunks have the same meaning in every .lp file:


Each .lp file must have a $MD5 chunk, and it marks the end of the .lp file's contents. The contents of the $MD5 chunk is the MD5 checksum of the entire .lp file up until the start of $MD5 chunk. A .lp file is not considered to be complete, and valid, unless it has a good $MD5 chunk.


A $GPG chunk is optional, and may follow the $MD5 chunk. It contains a detached GPG signature of the same data that's covered by the preceding $MD5 checksum.

Only one $GPG chunk may be present. A .lp file can only have one GPG signature.

7.1. Binary package files

The first chunk in a binary package file is always the MANIFEST chunk, whose contents are described in Section 7.3, “The Package Manifest File”. The MANIFEST chunk is followed by chunks whose names match the file installation number field, n, in the manifest's file records. These chunks contain the bzip2-compressed contents of the file to be installed.


Not every manifest file record has a corresponding chunk file, only the regular file records. File records that specify special files, such as directories, pipes, symbolic links, hard links, and device files, do not have corresponding chunk files.

7.2. Source package files

The first chunk in a .src.lp source package file is a SRCMANIFEST chunk. This chunk is a plain text file that contains a list of filenames, one per line. The second chunk in a source package file is a PACKAGES chunk. This is also a plain text file. It contains the names of all binary package files that were created when building the source package.

The remaining chunks in a source package files all have the same name, SRCFILE. There's one SRCFILE chunk for every filename listed in the SRCMANIFEST chunk. Each SRCFILE chunk gives the contents of its corresponding SRCMANIFEST filename.


The first filename in the SRCMANIFEST chunk, and the first SRCFILE chunk, is always the specfile.

7.3. The Package Manifest File

The manifest file is a catalog of all files installed by the package, plus additional information about a package. A manifest file is a text file. Each line in the text file is a record. The first character specifies the record type, and the rest of the line depends on the record type.

The possible records are:

Nname arch version release

The package's NAVR.


A required resource (see Required resources).


A temporarily required resource. This resource is only required to install the package (this resource is probably required only by the package's installation script which runs once when the package is installed, and is no longer needed afterwards). After installation this resource is no longer required.


A provided resource (see Provided resources).


A conflicting resource (see Conflicting resources).


An obsoleted resource (see Obsoleted resources).


A superceded resource (see Superceded resources).


An updated resource (see Updated resources).


All F records that follow specify files to be installed in directory pathname


This record specifies a single file installed by this package. This record consists of several fields, delimited by ASCII tab characters. The fields are:


The type of the file. See below for more information.


This is a list of characters that specifies which file attributes should be checked by lpm's --verify option. The individual characters come from the following list, and most files will include all of the following characters:


Verify the file's size.


Verify the file's permission mode.


Verify the file's recorded MD5 checksum.


Verify the file's type (FIFO, socket, block or character special device, etc...).


Verify the file's owner userid.


Verify the file's owner groupid.


Verify the file's timestamp.


The file installation number. This is a monotonically increasing counter, and points to a specific Fn.bz2 file in the package archive. Certain file types, such as directories or device nodes, don't have any actual content; this field is a single hyphen in those cases.

The only exception to a monotonically increasing counter is with hard links. A previously encountered file installation number indicates a hard link to the indicated file.


The file's owner. This is a username, not a numerical userid.


The file's group. This is a group name, not a numerical groupid.


The permissions on the file, as a decimal number.


The file's timestamp (a decimal number, number of seconds since start of epoch).


The name of the file. This is not the absolute filename, only the last component of the file's absolute pathname. The file's directory is specified by the most recent D record. The name of the file cannot contain control characters.


The size of the file, in bytes. This field is used for plain files only. This field is set to a hyphen for all other file types.


An opaque text string that represents the file's checksum. Plain text files use a checksum based on a SHA1 hash. For other files the checksum is a copy of the file's type.


This last, optional, field is used only for files that are symbolic links. It specifies the target of the symbolic link. The symbolic link target cannot contain control characters.


This record specifies an executable script. A package may specify that a script that will be run as part of the package's installation or uninstallation process. type specifies the script type:


Run this script just before installing the files in this package.


Run this script after the files in this package are installed.


Run this script just before uninstalling this package.


Run this script after uninstalling this package.

triggerin-resources, triggerun-resources, and triggerpostun-resources

This is a trigger script. resources is a comma-separated list of resources whose installation or uninstallation triggers the execution of the given script.

encscript is the encoded form of the script. The encoded form of the script is obtained by doubling all backslash characters in the script, and replacing all control characters in the script with \nn where nn is the character's two-digit decimal ASCII code, 00 through 31. This allows an arbitrary script to look like a single record line in the manifest file.


This is a miscellaneous header, either a build header or a package declaration header. When packages are built, the build headers from the specfile are placed into the manifest section of every binary package, together with the headers from the package declaration section of each package. Some headers are described in Section 2, “The build header” and Section 3, “Package declarations”. They are processed by lpbuild itself and are not placed in the manifest file (such as ExclusiveArch and BuildRequires, for example). All others go into the manifest file, as H records. encdata gives the contents of the header, encoded in the same format as an executable script, if it contains control characters.

Some headers are generated by lpbuild itself, and are added to the explicitly declared headers:


The name of the source package file from which this binary package was built.


The time when the package was built.


The estimated size of the package, when installed.


This header does not appear in the package file itself. When the package is installed, its manifest file is copied to the system package repository, and this header is added at the same time. This header contains the time the package was installed.

The Manifest object represents the manifest file. The Manifest object implements the following methods:

  • Return the package's name, as a NAVR.
  • Enumerate the required, provided, conflicting, obsoleted, superceded, and updated resources, as declared in the manifest file.
  • Enumerate all scripts declared in the manifest file.
  • The Manifest object can also pretend to be a Repository. Manifest is a Repository subclass. The Repository object implemented by a Manifest is a repository that contains one package manifest - itself, and installing or uninstalling package results in an error.

7.3.1. Manifest File Types

The following codes represent the type of a file:


A regular file.


A character device, major device number a, minor device b.


A block device, major device number a, minor device b.


A FIFO file.


A socket file.


A symbolic link.


A directory.

Most file types (where it makes sense to do so) may also be followed by a b, which marks a configuration file that might need backing up. Configuration files are marked for special processing. When uninstalling a package (which happens as part of a regular uninstall, or an upgrade to a newer version of the package) LPMtool checks if the contents of the file were changed. LPMtool keeps track of checksums of all installed files, and it checksums the file again before removing it. If the checksum is different, the file is not removed, but renamed as filename.lpmsave.YYYYMMDD-HHMMSS.

File types may also be followed by n to indicate that if the file already exists, it should not be overwritten, instead it's the new file that should get renamed.

7.3.2. Automatic Manifest dependencies

The Manifest object also implicitly creates a number of automatic dependencies. The following dependencies are not explicitly listed in the manifest file. They are created automatically by the Manifest object, as if they were explicitly listed:

  • Provides: name(arch)=version-release
  • Provides: name=version-release
  • Provides: filename=checksum, and Conflicts: filename!=checksum, for each file listed in the manifest. checksum is a checksum of the context of a regular file. For other kinds of files (directories, device files), checksum is the same as the file's type.

7.4. Metapackage files

The first chunk in a metapackage file, which by convention also has a .lp file extension, is a METAMANIFEST chunk. This chunk lists the packages that make up the metapackage, one package name per newline-terminated line.

The next, optional, chunk is a NAME chunk, that gives the descriptive name of the metapackage. LPMtool displays the name when asking for confirmation to install the metapackage. The descriptive name in the NAME chunk is encoded using the UTF-8 character set.

The remaining chunks in the metapackage files are one or more REPOSITORY chunks, optionally preceded by an AUTHKEY chunk. In nearly all cases only one REPOSITORY chunk is present. Although permitted, having more than one REPOSITORY chunks present will result in unnecessary confusion.

REPOSITORY chunks also contain plain text content. The first line gives the URL of the package repository that publishes the packages listed in the preceding METAMANIFEST chunk. The rest of the REPOSITORY chunk contains the repository's ASCII-armored public keychain.

If access to the package repository is restricted, the preceding AUTHKEY chunk contains the authorization key for the repository.