[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]


Ubuntu Policy Manual
Chapter 5 - Control files and their fields

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


5.1 Syntax of control files

A control file consists of one or more paragraphs of fields[33]. 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 (logical) 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.

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

In fields where it is specified that lines may not wrap, 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.

All control files must be encoded in UTF-8.


5.2 Source package control files -- 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. Many fields are permitted to span multiple lines in debian/control but not in any other control file. These tools are responsible for removing the line breaks from such fields when using fields from debian/control to generate other control files.

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.10 for details.

In addition to the control file syntax described above, this file may also contain comment lines starting with # without any preceding whitespace. All such lines are ignored, even in the middle of continuation lines for a multiline field, and do not end a multiline field.


5.3 Binary package control files -- DEBIAN/control

The DEBIAN/control file contains the most vital (and version-dependent) information about a binary package.

The fields in this file are:


5.4 Debian source control files -- .dsc

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.


5.5 Debian changes files -- .changes

The .changes files are used by the Ubuntu 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:


5.6 List of fields


5.6.1 Source

This field identifies the source package name.

In debian/control or a .dsc file, this field must contain only the name of the source package.

In a binary package control file or a .changes file, the source package name may be followed by a version number in parentheses[34]. 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.

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.


5.6.2 Maintainer

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


5.6.3 Uploaders

List of the names and email addresses of co-maintainers of the package, if any. If the package has other maintainers beside the one named in the Maintainer field, their names and email addresses should be listed here. The format is the same as that of the Maintainer tag, and multiple entries should be comma separated. Currently, this field is restricted to a single line of data. This is an optional field.

Any parser that interprets the Uploaders field in debian/control must permit it to span multiple lines. Line breaks in an Uploaders field that spans multiple lines are not significant and the semantics of the field are the same as if the line breaks had not been present.


5.6.4 Changed-By

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.


5.6.5 Section

This field specifies an application area into which the package has been classified. See Sections, 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.


5.6.6 Priority

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.


5.6.7 Package

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.


5.6.8 Architecture

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

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

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.9 for information how to get the architecture for the build process.


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.


5.6.10 Package interrelationship fields: Depends, Pre-Depends, Recommends, Suggests, Breaks, Conflicts, Provides, Replaces, Enhances

These fields describe the package's relationships with other packages. Their syntax and semantics are described in Declaring relationships between packages, Chapter 7.


5.6.11 Standards-Version

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

Ubuntu: Packages should not include the Ubuntu revision of the policy manual (e.g. "ubuntu1" in "3.8.0.1ubuntu1") in their Standards-Version field. This tends to create unnecessary diffs relative to Debian. For the same reason, Ubuntu developers should not generally change the Standards-Version field in packages originating in Debian.


5.6.12 Version

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[38] and the characters . + - : ~ (full stop, plus, hyphen, colon, tilde) 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 Ubuntu package based on the upstream version. It may contain only alphanumerics and the characters + . ~ (plus, full stop, tilde) 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 or Ubuntu package, and so there is only one "debianisation" 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 is equivalent to a debian_revision of 0.

Ubuntu: The string "ubuntu" in a version number instructs the archive management software not to copy newer versions of the package from Debian automatically. It should therefore be used when modifying packages relative to Debian, taking care that the Ubuntu version number compares less than the next expected version in Debian. For example, the first Ubuntu modification of version 1.0-1 in Debian would be 1.0-1ubuntu1.

When comparing two version numbers, first the epoch of each are compared, then the upstream_version if epoch is equal, and then debian_revision if upstream_version is also equal. epoch is compared numerically. The upstream_version and debian_revision parts are compared by the package management system using the following 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 and so that a tilde sorts before anything, even the end of a part. For example, the following parts are in sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a.[39]

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


5.6.13 Description

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.


5.6.14 Distribution

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


5.6.15 Date

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 Ubuntu changelog: debian/changelog, Section 4.4).


5.6.16 Format

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


5.6.17 Urgency

This is a description of how important it is to upgrade to this version from previous ones. It consists of a single keyword taking one of the values low, medium, high, emergency, or critical[42] (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 Ubuntu changelog: debian/changelog, Section 4.4.


5.6.18 Changes

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 consisting only of a space and a full stop.

The value of this field is usually extracted from the debian/changelog file - see Ubuntu 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).


5.6.19 Binary

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[43]. Currently the packages must be separated using only spaces in the .changes file.


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


5.6.21 Files

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[44]. 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 Ubuntu 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.


5.6.22 Closes

A space-separated list of Debian bug report numbers that the upload governed by the .changes file closes.


5.6.23 Launchpad-Bugs-Fixed

A space-separated list of Launchpad bug report numbers that the upload governed by the .changes file closes.


5.6.24 Homepage

The URL of the web site for this package, preferably (when applicable) the site from which the original source can be obtained and any additional upstream documentation or information may be found. The content of this field is a simple URL without any surrounding characters such as <>.


5.7 User-defined fields

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.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ next ]


Ubuntu Policy Manual

version 3.8.2.0ubuntu1, 2009-06-19

The Debian Policy Mailing List
The Ubuntu Developers Mailing List