The package management system manipulates data represented in a common format,
known as control data, stored in control files. Control
files are used for source packages, binary packages and the
.changes
files which control the installation of uploaded files[24].
A control file consists of one or more paragraphs of fields[25]. The paragraphs are separated by blank lines. Some control files allow only one paragraph; others allow several, in which case each paragraph usually refers to a different package. (For example, in source packages, the first paragraph refers to the source package, and later paragraphs refer to binary packages generated from the source.)
Each paragraph consists of a series of data fields; each field consists of the field name, followed by a colon and then the data/value associated with that field. It ends at the end of the line. Horizontal whitespace (spaces and tabs) may occur immediately before or after the value and is ignored there; it is conventional to put a single space after the colon. For example, a field might be:
Package: libc6
the field name is Package and the field value libc6.
Some fields' values may span several lines; in this case each continuation line must start with a space or a tab. Any trailing spaces or tabs at the end of individual lines of a field value are ignored.
Except where otherwise stated, only a single line of data is allowed and whitespace is not significant in a field body. Whitespace must not appear inside names (of packages, architectures, files or anything else) or version numbers, or between the characters of multi-character version relationships.
Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below.
Blank lines, or lines consisting only of spaces and tabs, are not allowed within field values or between fields - that would mean a new paragraph.
debian/control
The debian/control
file contains the most vital (and
version-independent) information about the source package and about the binary
packages it creates.
The first paragraph of the control file contains information about the source package in general. The subsequent sets each describe a binary package that the source tree builds.
The fields in the general paragraph (the first one, for the source package) are:
The fields in the binary package paragraphs are:
The syntax and semantics of the fields are described below.
These fields are used by dpkg-gencontrol
to generate control files
for binary packages (see below), by dpkg-genchanges
to generate
the .changes file to accompany the upload, and by
dpkg-source
when it creates the .dsc
source control
file as part of a source archive.
The fields here may contain variable references - their values will be
substituted by dpkg-gencontrol
, dpkg-genchanges
or
dpkg-source
when they generate output control files. See Variable substitutions:
debian/substvars
, Section 4.9 for details.
DEBIAN/control
The DEBIAN/control
file contains the most vital (and
version-dependent) information about a binary package.
The fields in this file are:
This file contains a series of fields, identified and separated just like the fields in the control file of a binary package. The fields are listed below; their syntax is described above, in Control files and their fields (from old Packaging Manual), Appendix D.
The source package control file is generated by dpkg-source
when
it builds the source archive, from other files in the source package, described
above. When unpacking, it is checked against the files and directories in the
other parts of the source package.
.changes
The .changes files are used by the Debian archive maintenance software to process updates to packages. They contain one paragraph which contains information from the debian/control file and other data about the source package gathered via debian/changelog and debian/rules.
The fields in this file are:
This field identifies the source package name.
In a main source control information, a .changes
or a
.dsc
file this may contain only the name of the source package.
In the control file of a binary package it may be followed by a version number
in parentheses[26]. This version
number may be omitted (and is, by dpkg-gencontrol
) if it has the
same value as the Version field of the binary package in question.
The field itself may be omitted from a binary package control file when the
source package has the same name and version as the binary package.
The package maintainer's name and email address. The name should come first, then the email address inside angle brackets <> (in RFC822 format).
If the maintainer's name contains a full stop then the whole field will not work directly as an email address due to a misfeature in the syntax specified in RFC822; a program using this field as an address must check for this and correct the problem if necessary (for example by putting the name in round brackets and moving it to the end, and bringing the email address forward).
The name and email address of the person who changed the said package. Usually the name of the maintainer. All the rules for the Maintainer field apply here, too.
This field specifies an application area into which the package has been classified. See Subsections, Section 2.4.
When it appears in the debian/control
file, it gives the value for
the subfield of the same name in the Files field of the
.changes
file. It also gives the default for the same field in
the binary packages.
By default, dpkg-gencontrol
does not include this field in the
control file of a binary package - use the -is (or
-isp) options to achieve this effect.
This field represents how important that it is that the user have the package installed. See Priorities, Section 2.5.
When it appears in the debian/control
file, it gives the value for
the subfield of the same name in the Files field of the
.changes
file. It also gives the default for the same field in
the binary packages.
By default, dpkg-gencontrol
does not include this field in the
control file of a binary package - use the -ip (or
-isp) options to achieve this effect.
The name of the binary package.
Package names must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character.
Depending on context and the control file used, the Architecture field can include the following sets of values:
In the main debian/control
file in the source package, or in the
source package control file .dsc
, one may specify a list of
architectures separated by spaces, or the special values any or
all.
Specifying any indicates that the source package isn't dependent on any particular architecture and should compile fine on any one. The produced binary package(s) will be specific to whatever the current build architecture is.[27]
Specifying a list of architectures indicates that the source will build an architecture-dependent package, and will only work correctly on the listed architectures.[28]
In a .changes
file, the Architecture field lists the
architecture(s) of the package(s) currently being uploaded. This will be a
list; if the source for the package is also being uploaded, the special entry
source is also present.
See Main building script:
debian/rules
, Section 4.8 for information how to get the
architecture for the build process.
This is a boolean field which may occur only in the control file of a binary package or in a per-package fields paragraph of a main source control data file.
If set to yes then the package management system will refuse to remove the package (upgrading and replacing it is still possible). The other possible value is no, which is the same as not having the field at all.
These fields describe the package's relationships with other packages. Their syntax and semantics are described in Declaring relationships between packages, Chapter 7.
The most recent version of the standards (the policy manual and associated texts) with which the package complies.
The version number has four components: major and minor version number and major and minor patch level. When the standards change in a way that requires every package to change the major number will be changed. Significant changes that will require work in many packages will be signaled by a change to the minor number. The major patch level will be changed for any change to the meaning of the standards, however small; the minor patch level will be changed when only cosmetic, typographical or other edits are made which neither change the meaning of the document nor affect the contents of packages.
Thus only the first three components of the policy version are significant in the Standards-Version control field, and so either these three components or the all four components may be specified.[29]
The version number of a package. The format is: [epoch:]upstream_version[-debian_revision]
The three components here are:
It is provided to allow mistakes in the version numbers of older versions of a package, and also a package's previous version numbering schemes, to be left behind.
.deb
file has been made, if this is applicable. Usually this will be in the same
format as that specified by the upstream author(s); however, it may need to be
reformatted to fit into the package management system's format and comparison
scheme.
The comparison behavior of the package management system with respect to the upstream_version is described below. The upstream_version portion of the version number is mandatory.
The upstream_version may contain only alphanumerics[30] and the characters . + - : (full stop, plus, hyphen, colon) and should start with a digit. If there is no debian_revision then hyphens are not allowed; if there is no epoch then colons are not allowed.
It is optional; if it isn't present then the upstream_version may not contain a hyphen. This format represents the case where a piece of software was written specifically to be turned into a Debian package, and so there is only one "debianization" of it and therefore no revision indication is required.
It is conventional to restart the debian_revision at 1 each time the upstream_version is increased.
The package management system will break the version number apart at the last hyphen in the string (if there is one) to determine the upstream_version and debian_revision. The absence of a debian_revision compares earlier than the presence of one (but note that the debian_revision is the least significant part of the version number).
The upstream_version and debian_revision parts are compared by the package management system using the same algorithm:
The strings are compared from left to right.
First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters.
Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero.
These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted.
Note that the purpose of epochs is to allow us to leave behind mistakes in version numbering, and to cope with situations where the version numbering scheme changes. It is not intended to cope with version numbers containing strings of letters which the package management system cannot interpret (such as ALPHA or pre-), or with silly orderings (the author of this manual has heard of a package whose versions went 1.1, 1.2, 1.3, 1, 2.1, 2.2, 2 and so forth).
In a source or binary control file, the Description field contains a description of the binary package, consisting of two parts, the synopsis or the short description, and the long description. The field's format is as follows:
Description: <single line synopsis> <extended description over several lines>
The lines in the extended description can have these formats:
Do not use tab characters. Their effect is not predictable.
See The description of a package, Section 3.4 for further information on this.
In a .changes
file, the Description field contains a
summary of the descriptions for the packages being uploaded.
The part of the field before the first newline is empty; thereafter each line has the name of a binary package and the summary description line from that binary package. Each line is indented by one space.
In a .changes
file or parsed changelog output this contains the
(space-separated) name(s) of the distribution(s) where this version of the
package should be installed. Valid distributions are determined by the archive
maintainers.[32]
This field includes the date the package was built or last edited.
The value of this field is usually extracted from the
debian/changelog
file - see Debian changelog:
debian/changelog
, Section 4.4).
This field specifies a format revision for the file. The most current format described in the Policy Manual is version 1.5. The syntax of the format value is the same as that of a package version number except that no epoch or Debian revision is allowed - see Version, Section 5.6.11.
This is a description of how important it is to upgrade to this version from previous ones. It consists of a single keyword usually taking one of the values low, medium or high (not case-sensitive) followed by an optional commentary (separated by a space) which is usually in parentheses. For example:
Urgency: low (HIGH for users of diversions)
The value of this field is usually extracted from the
debian/changelog
file - see Debian changelog:
debian/changelog
, Section 4.4.
This field contains the human-readable changes data, describing the differences between the last version and the current one.
There should be nothing in this field before the first newline; all the subsequent lines must be indented by at least one space; blank lines must be represented by a line consiting only of a space and a full stop.
The value of this field is usually extracted from the
debian/changelog
file - see Debian changelog:
debian/changelog
, Section 4.4).
Each version's change information should be preceded by a "title" line giving at least the version, distribution(s) and urgency, in a human-readable way.
If data from several versions is being returned the entry for the most recent version should be returned first, and entries should be separated by the representation of a blank line (the "title" line may also be followed by the representation of blank line).
This field is a list of binary packages.
When it appears in the .dsc
file it is the list of binary packages
which a source package can produce. It does not necessarily produce all of
these binary packages for every architecture. The source control file doesn't
contain details of which architectures are appropriate for which of the binary
packages.
When it appears in a .changes
file it lists the names of the
binary packages actually being uploaded.
The syntax is a list of binary packages separated by commas[33]. Currently the packages must be
separated using only spaces in the .changes
file.
This field appears in the control files of binary packages, and in the
Packages
files. It gives the total amount of disk space required
to install the named package.
The disk space is represented in kilobytes as a simple decimal number.
This field contains a list of files with information about each one. The exact information and syntax varies with the context. In all cases the part of the field contents on the same line as the field name is empty. The remainder of the field is one line per file, each line being indented by one space and containing a number of sub-fields separated by spaces.
In the .dsc
file, each line contains the MD5 checksum, size and
filename of the tar file and (if applicable) diff file which make up the
remainder of the source package[34]. The exact forms of the filenames are described in Source packages as archives,
Section C.3.
In the .changes
file this contains one line per file being
uploaded. Each line contains the MD5 checksum, size, section and priority and
the filename. The section and priority are the values of the corresponding fields in
the main source control file. If no section or priority is specified then
- should be used, though section and priority values must be
specified for new packages to be installed properly.
The special value byhand for the section in a .changes file indicates that the file in question is not an ordinary package file and must by installed by hand by the distribution maintainers. If the section is byhand the priority should be -.
If a new Debian revision of a package is being shipped and no new original
source archive is being distributed the .dsc must still contain
the Files field entry for the original source archive
package-upstream-version.orig.tar.gz
, but
the .changes
file should leave it out. In this case the original
source archive on the distribution site must match exactly, byte-for-byte, the
original source archive which was used to generate the .dsc
file
and diff which are being uploaded.
A space-separated list of bug report numbers that the upload governed by the .changes file closes.
Additional user-defined fields may be added to the source package control file. Such fields will be ignored, and not copied to (for example) binary or source package control files or upload control files.
If you wish to add additional unsupported fields to these output files you should use the mechanism described here.
Fields in the main source control information file with names starting X, followed by one or more of the letters BCS and a hyphen -, will be copied to the output files. Only the part of the field name after the hyphen will be used in the output file. Where the letter B is used the field will appear in binary package control files, where the letter S is used in source package control files and where C is used in upload control (.changes) files.
For example, if the main source information control file contains the field
XBS-Comment: I stand between the candle and the star.
then the binary and source package control files will contain the field
Comment: I stand between the candle and the star.
Debian Policy Manual
version 3.6.1.1, 2004-06-25