APS:Headers

Package (mandatory)

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.

Source

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[27]. 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.

Version (mandatory)

The version number of a package. The format is: [epoch:]upstream_version[-debian_revision]

The three components here are: epoch

This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed. If it is omitted then the upstream_version may not contain any colons.

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

This is the main part of the version number. It is usually the version number of the original ("upstream") package from which the .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[31] 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. debian_revision

This part of the version number specifies the version of the Debian package based on the upstream version. It may contain only alphanumerics and the characters + and . (plus and full stop) and is compared in the same way as the upstream_version is.

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

Type (mandatory)

Priority (recommended)

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.

Architecture (mandatory)

Depending on context and the control file used, the Architecture field can include the following sets of values:

A unique single word identifying a Debian machine architecture, see Architecture specification strings, Section 11.1.

all, which indicates an architecture-independent package.

any, which indicates a package available for building on any architecture.

source, which indicates a source package.

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.[28]

Specifying a list of architectures indicates that the source will build an architecture-dependent package, and will only work correctly on the listed architectures.[29]

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.

Essential

5.6.9 Essential

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.

Depends et al

http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

Installed-Size

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.

Uploader (mandatory)

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

Short (mandatory)