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:
$MD5
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.
$GPG
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.
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.
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.
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 releaseThe package's NAVR.
rresourceA required resource (see Required resources).
eresourceA 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.
presourceA provided resource (see Provided resources).
cresourceA conflicting resource (see Conflicting resources).
oresourceAn obsoleted resource (see Obsoleted resources).
sresourceA superceded resource (see Superceded resources).
uresourceAn updated resource (see Updated resources).
DpathnameAll “F” records that follow specify files to be installed in directory “pathname”
Ft<TAB>v<TAB>n<TAB>u<TAB>g<TAB>m<TAB>ts<TAB>f<TAB>z<TAB>c<TAB>sThis record specifies a single file installed by this package. This record consists of several fields, delimited by ASCII tab characters. The fields are:
tThe type of the file. See below for more information.
v
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:
SVerify the file's size.
MVerify the file's permission mode.
5Verify the file's recorded MD5 checksum.
DVerify the file's type (FIFO, socket, block or character special device, etc...).
UVerify the file's owner userid.
GVerify the file's owner groupid.
TVerify the file's timestamp.
nThe 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.
uThe file's owner. This is a username, not a numerical userid.
gThe file's group. This is a group name, not a numerical groupid.
mThe permissions on the file, as a decimal number.
tsThe file's timestamp (a decimal number, number of seconds since start of epoch).
fThe 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.
zThe 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.
cAn 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.
sThis 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.
Ttype<TAB>encscriptThis 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.
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.
Hname<TAB>encdata
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:
SourceThe name of the source package file from which this binary package was built.
BUILDDATEThe time when the package was built.
SIZEThe estimated size of the package, when installed.
INSTALLDATEThis 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:
The following codes represent the type of a file:
FA regular file.
Ca,b
A character device, major device number
a, minor device
b.
Ba,b
A block device, major device number
a, minor device
b.
IA FIFO file.
SA socket file.
LA symbolic link.
DA 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.
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-releaseProvides: name=version-releaseProvides: 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.
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.