формат главного управляющего файла пакетов исходного кода Debian (Debian source packages' master control file format)
SOURCE FIELDS
Source: source-package-name (required)
The value of this field is the name of the source package,
and should match the name of the source package in the
debian/changelog file. A package name must consist only of
lowercase letters (a-z), digits (0-9), plus (+) and minus
(-) signs, and periods (.). Package names must be at least
two characters long and must start with a lowercase
alphanumeric character (a-z0-9).
Maintainer: fullname-email (recommended)
Should be in the format «Joe Bloggs <jbloggs@foo.com>»,
and references the person who currently maintains the
package, as opposed to the author of the software or the
original packager.
Uploaders: fullname-email
Lists all the names and email addresses of co-maintainers
of the package, in the same format as the Maintainer
field. Multiple co-maintainers should be separated by a
comma.
Standards-Version: version-string
This documents the most recent version of the distribution
policy standards this package complies with.
Description short-description
long-description
The format for the source package description is a short
brief summary on the first line (after the Description
field). The following lines should be used as a longer,
more detailed description. Each line of the long
description must be preceded by a space, and blank lines
in the long description must contain a single '.'
following the preceding space.
Homepage: url
The upstream project home page URL.
Bugs: url
The url of the bug tracking system for this package. The
current used format is bts-type://bts-address, like
debbugs://bugs.debian.org. This field is usually not
needed.
Rules-Requires-Root: no|binary-targets|impl-keywords
This field is used to indicate whether the debian/rules
file requires (fake)root privileges to run some of its
targets, and if so when.
no The binary targets will not require (fake)root at
all.
binary-targets
The binary targets must always be run under
(fake)root. This value is the default when the
field is omitted; adding the field with an explicit
binary-targets while not strictly needed, marks it
as having been analyzed for this requirement.
impl-keywords
This is a space-separated list of keywords which
define when (fake)root is required.
Keywords consist of namespace/cases. The namespace
part cannot contain "/" or whitespace. The cases
part cannot contain whitespace. Furthermore, both
parts must consist entirely of printable ASCII
characters.
Each tool/package will define a namespace named
after itself and provide a number of cases where
(fake)root is required. (See "Implementation
provided keywords" in rootless-builds.txt).
When the field is set to one of the impl-keywords,
the builder will expose an interface that is used
to run a command under (fake)root. (See "Gain Root
API" in rootless-builds.txt.)
Testsuite: name-list
Testsuite-Triggers: package-list
These fields are described in the dsc(5) manual page, as
they are generated from information inferred from
debian/tests/control or copied literally to the source
control file.
Vcs-Arch: url
Vcs-Bzr: url
Vcs-Cvs: url
Vcs-Darcs: url
Vcs-Git: url
Vcs-Hg: url
Vcs-Mtn: url
Vcs-Svn: url
The url of the Version Control System repository used to
maintain this package. Currently supported are Arch, Bzr
(Bazaar), Cvs, Darcs, Git, Hg (Mercurial), Mtn (Monotone)
and Svn (Subversion). Usually this field points to the
latest version of the package, such as the main branch or
the trunk.
Vcs-Browser: url
The url of a webinterface to browse the Version Control
System repository.
Origin: name
The name of the distribution this package is originating
from. This field is usually not needed.
Section: section
This is a general field that gives the package a category
based on the software that it installs. Some common
sections are utils, net, mail, text, x11, etc.
Priority: priority
Sets the importance of this package in relation to the
system as a whole. Common priorities are required,
standard, optional, extra, etc.
The Section and Priority fields usually have a defined set
of accepted values based on the specific distribution
policy.
Build-Depends: package-list
A list of packages that need to be installed and
configured to be able to build from source package. These
dependencies need to be satisfied when building binary
architecture dependent or independent packages and source
packages. Including a dependency in this field does not
have the exact same effect as including it in both
Build-Depends-Arch and Build-Depends-Indep, because the
dependency also needs to be satisfied when building the
source package.
Build-Depends-Arch: package-list
Same as Build-Depends, but they are only needed when
building the architecture dependent packages. The
Build-Depends are also installed in this case. This field
is supported since dpkg 1.16.4; in order to build with
older dpkg versions, Build-Depends should be used instead.
Build-Depends-Indep: package-list
Same as Build-Depends, but they are only needed when
building the architecture independent packages. The
Build-Depends are also installed in this case.
Build-Conflicts: package-list
A list of packages that should not be installed when the
package is built, for example because they interfere with
the build system used. Including a dependency in this
list has the same effect as including it in both
Build-Conflicts-Arch and Build-Conflicts-Indep, with the
additional effect of being used for source-only builds.
Build-Conflicts-Arch: package-list
Same as Build-Conflicts, but only when building the
architecture dependent packages. This field is supported
since dpkg 1.16.4; in order to build with older dpkg
versions, Build-Conflicts should be used instead.
Build-Conflicts-Indep: package-list
Same as Build-Conflicts, but only when building the
architecture independent packages.
The syntax of the Build-Depends, Build-Depends-Arch and
Build-Depends-Indep fields is a list of groups of alternative
packages. Each group is a list of packages separated by vertical
bar (or 'pipe') symbols, '|'. The groups are separated by commas
',', and can end with a trailing comma that will be eliminated
when generating the fields for deb-control(5) (since dpkg
1.10.14). Commas are to be read as 'AND', and pipes as 'OR',
with pipes binding more tightly. Each package name is optionally
followed by an architecture qualifier appended after a colon ':',
optionally followed by a version number specification in
parentheses '(' and ')', an architecture specification in square
brackets '[' and ']', and a restriction formula consisting of one
or more lists of profile names in angle brackets '<' and '>'.
The syntax of the Build-Conflicts, Build-Conflicts-Arch and
Build-Conflicts-Indep fields is a list of comma-separated package
names, where the comma is read as an 'AND', and where the list
can end with a trailing comma that will be eliminated when
generating the fields for deb-control(5) (since dpkg 1.10.14).
Specifying alternative packages using a 'pipe' is not supported.
Each package name is optionally followed by a version number
specification in parentheses, an architecture specification in
square brackets, and a restriction formula consisting of one or
more lists of profile names in angle brackets.
An architecture qualifier name can be a real Debian architecture
name (since dpkg 1.16.5), any (since dpkg 1.16.2) or native
(since dpkg 1.16.5). If omitted, the default for Build-Depends
fields is the current host architecture, the default for
Build-Conflicts fields is any. A real Debian architecture name
will match exactly that architecture for that package name, any
will match any architecture for that package name if the package
is marked with Multi-Arch: allowed, and native will match the
current build architecture if the package is not marked with
Multi-Arch: foreign.
A version number may start with a '>>', in which case any later
version will match, and may specify or omit the Debian packaging
revision (separated by a hyphen). Accepted version relationships
are '>>' for greater than, '<<' for less than, '>=' for greater
than or equal to, '<=' for less than or equal to, and '=' for
equal to.
An architecture specification consists of one or more
architecture names, separated by whitespace. Exclamation marks
may be prepended to each of the names, meaning 'NOT'.
A restriction formula consists of one or more restriction lists,
separated by whitespace. Each restriction list is enclosed in
angle brackets. Items in the restriction list are build profile
names, separated by whitespace and can be prefixed with an
exclamation mark, meaning 'NOT'. A restriction formula
represents a disjunctive normal form expression.
Note that dependencies on packages in the build-essential set can
be omitted and that declaring build conflicts against them is
impossible. A list of these packages is in the build-essential
package.
