1deb-src-control(5)                dpkg suite                deb-src-control(5)
2
3
4

NAME

6       deb-src-control - Debian source packages' master control file format
7

SYNOPSIS

9       debian/control
10

DESCRIPTION

12       Each Debian source package contains the master «debian/control» file,
13       and its deb822(5) format is a superset of the control file shipped in
14       Debian binary packages, see deb-control(5).
15
16       This file contains at least 2 paragraphs, separated by a blank line.
17       The first paragraph lists all information about the source package in
18       general, while each following paragraph describes exactly one binary
19       package. Each paragraph consists of at least one field. A field starts
20       with a fieldname, such as Package or Section (case insensitive),
21       followed by a colon, the body of the field (case sensitive unless
22       stated otherwise) and a newline.  Multi-line fields are also allowed,
23       but each supplementary line, without a fieldname, should start with at
24       least one space. The content of the multi-line fields is generally
25       joined to a single line by the tools (except in the case of the
26       Description field, see below). To insert empty lines into a multi-line
27       field, insert a dot after the space.  Lines starting with a ‘#’ are
28       treated as comments.
29

SOURCE FIELDS

31       Source: source-package-name (required)
32           The value of this field is the name of the source package, and
33           should match the name of the source package in the debian/changelog
34           file. A package name must consist only of lowercase letters (a-z),
35           digits (0-9), plus (+) and minus (-) signs, and periods (.).
36           Package names must be at least two characters long and must start
37           with a lowercase alphanumeric character (a-z0-9).
38
39       Maintainer: fullname-email (recommended)
40           Should be in the format «Joe Bloggs <jbloggs@foo.com>», and
41           references the person who currently maintains the package, as
42           opposed to the author of the software or the original packager.
43
44       Uploaders: fullname-email
45           Lists all the names and email addresses of co-maintainers of the
46           package, in the same format as the Maintainer field.  Multiple co-
47           maintainers should be separated by a comma.
48
49       Standards-Version: version-string
50           This documents the most recent version of the distribution policy
51           standards this package complies with.
52
53       Description short-description
54        long-description
55           The format for the source package description is a short brief
56           summary on the first line (after the Description field).  The
57           following lines should be used as a longer, more detailed
58           description.  Each line of the long description must be preceded by
59           a space, and blank lines in the long description must contain a
60           single ‘.’ following the preceding space.
61
62       Homepage: url
63           The upstream project home page URL.
64
65       Bugs: url
66           The url of the bug tracking system for this package. The current
67           used format is bts-type://bts-address, like
68           debbugs://bugs.debian.org. This field is usually not needed.
69
70       Rules-Requires-Root: no|binary-targets|impl-keywords
71           This field is used to indicate whether the debian/rules file
72           requires (fake)root privileges to run some of its targets, and if
73           so when.
74
75           no  The binary targets will not require (fake)root at all.
76
77           binary-targets
78               The binary targets must always be run under (fake)root.  This
79               value is the default when the field is omitted; adding the
80               field with an explicit binary-targets while not strictly
81               needed, marks it as having been analyzed for this requirement.
82
83           impl-keywords
84               This is a space-separated list of keywords which define when
85               (fake)root is required.
86
87               Keywords consist of namespace/cases.  The namespace part cannot
88               contain "/" or whitespace.  The cases part cannot contain
89               whitespace.  Furthermore, both parts must consist entirely of
90               printable ASCII characters.
91
92               Each tool/package will define a namespace named after itself
93               and provide a number of cases where (fake)root is required.
94               (See "Implementation provided keywords" in
95               rootless-builds.txt).
96
97               When the field is set to one of the impl-keywords, the builder
98               will expose an interface that is used to run a command under
99               (fake)root.  (See "Gain Root API" in rootless-builds.txt.)
100
101       Testsuite: name-list
102       Testsuite-Triggers: package-list
103           These fields are described in the dsc(5) manual page, as they are
104           generated from information inferred from debian/tests/control or
105           copied literally to the source control file.
106
107       Vcs-Arch: url
108       Vcs-Bzr: url
109       Vcs-Cvs: url
110       Vcs-Darcs: url
111       Vcs-Git: url
112       Vcs-Hg: url
113       Vcs-Mtn: url
114       Vcs-Svn: url
115           The url of the Version Control System repository used to maintain
116           this package. Currently supported are Arch, Bzr (Bazaar), Cvs,
117           Darcs, Git, Hg (Mercurial), Mtn (Monotone) and Svn (Subversion).
118           Usually this field points to the latest version of the package,
119           such as the main branch or the trunk.
120
121       Vcs-Browser: url
122           The url of a webinterface to browse the Version Control System
123           repository.
124
125       Origin: name
126           The name of the distribution this package is originating from. This
127           field is usually not needed.
128
129       Section: section
130           This is a general field that gives the package a category based on
131           the software that it installs.  Some common sections are utils,
132           net, mail, text, x11, etc.
133
134       Priority: priority
135           Sets the importance of this package in relation to the system as a
136           whole.  Common priorities are required, standard, optional, extra,
137           etc.
138
139           The Section and Priority fields usually have a defined set of
140           accepted values based on the specific distribution policy.
141
142       Build-Depends: package-list
143           A list of packages that need to be installed and configured to be
144           able to build from source package.  These dependencies need to be
145           satisfied when building binary architecture dependent or
146           independent packages and source packages.  Including a dependency
147           in this field does not have the exact same effect as including it
148           in both Build-Depends-Arch and Build-Depends-Indep, because the
149           dependency also needs to be satisfied when building the source
150           package.
151
152       Build-Depends-Arch: package-list
153           Same as Build-Depends, but they are only needed when building the
154           architecture dependent packages. The Build-Depends are also
155           installed in this case. This field is supported since dpkg 1.16.4;
156           in order to build with older dpkg versions, Build-Depends should be
157           used instead.
158
159       Build-Depends-Indep: package-list
160           Same as Build-Depends, but they are only needed when building the
161           architecture independent packages. The Build-Depends are also
162           installed in this case.
163
164       Build-Conflicts: package-list
165           A list of packages that should not be installed when the package is
166           built, for example because they interfere with the build system
167           used.  Including a dependency in this list has the same effect as
168           including it in both Build-Conflicts-Arch and Build-Conflicts-
169           Indep, with the additional effect of being used for source-only
170           builds.
171
172       Build-Conflicts-Arch: package-list
173           Same as Build-Conflicts, but only when building the architecture
174           dependent packages. This field is supported since dpkg 1.16.4; in
175           order to build with older dpkg versions, Build-Conflicts should be
176           used instead.
177
178       Build-Conflicts-Indep: package-list
179           Same as Build-Conflicts, but only when building the architecture
180           independent packages.
181
182       The syntax of the Build-Depends, Build-Depends-Arch and Build-Depends-
183       Indep fields is a list of groups of alternative packages.  Each group
184       is a list of packages separated by vertical bar (or “pipe”) symbols,
185|’.  The groups are separated by commas ‘,’, and can end with a
186       trailing comma that will be eliminated when generating the fields for
187       deb-control(5) (since dpkg 1.10.14).  Commas are to be read as “AND”,
188       and pipes as “OR”, with pipes binding more tightly.  Each package name
189       is optionally followed by an architecture qualifier appended after a
190       colon ‘:’, optionally followed by a version number specification in
191       parentheses ‘(’ and ‘)’, an architecture specification in square
192       brackets ‘[’ and ‘]’, and a restriction formula consisting of one or
193       more lists of profile names in angle brackets ‘<’ and ‘>’.
194
195       The syntax of the Build-Conflicts, Build-Conflicts-Arch and Build-
196       Conflicts-Indep fields is a list of comma-separated package names,
197       where the comma is read as an “AND”, and where the list can end with a
198       trailing comma that will be eliminated when generating the fields for
199       deb-control(5) (since dpkg 1.10.14).  Specifying alternative packages
200       using a “pipe” is not supported.  Each package name is optionally
201       followed by a version number specification in parentheses, an
202       architecture specification in square brackets, and a restriction
203       formula consisting of one or more lists of profile names in angle
204       brackets.
205
206       An architecture qualifier name can be a real Debian architecture name
207       (since dpkg 1.16.5), any (since dpkg 1.16.2) or native (since dpkg
208       1.16.5).  If omitted, the default for Build-Depends fields is the
209       current host architecture, the default for Build-Conflicts fields is
210       any.  A real Debian architecture name will match exactly that
211       architecture for that package name, any will match any architecture for
212       that package name if the package is marked with Multi-Arch: allowed,
213       and native will match the current build architecture if the package is
214       not marked with Multi-Arch: foreign.
215
216       A version number may start with a ‘>>’, in which case any later version
217       will match, and may specify or omit the Debian packaging revision
218       (separated by a hyphen).  Accepted version relationships are ‘>>’ for
219       greater than, ‘<<’ for less than, ‘>=’ for greater than or equal to,
220<=’ for less than or equal to, and ‘=’ for equal to.
221
222       An architecture specification consists of one or more architecture
223       names, separated by whitespace. Exclamation marks may be prepended to
224       each of the names, meaning “NOT”.
225
226       A restriction formula consists of one or more restriction lists,
227       separated by whitespace. Each restriction list is enclosed in angle
228       brackets. Items in the restriction list are build profile names,
229       separated by whitespace and can be prefixed with an exclamation mark,
230       meaning “NOT”.  A restriction formula represents a disjunctive normal
231       form expression.
232
233       Note that dependencies on packages in the build-essential set can be
234       omitted and that declaring build conflicts against them is impossible.
235       A list of these packages is in the build-essential package.
236

BINARY FIELDS

238       Note that the Priority, Section and Homepage fields can also be in a
239       binary paragraph to override the global value from the source package.
240
241       Package: binary-package-name (required)
242           This field is used to name the binary package name. The same
243           restrictions as to a source package name apply.
244
245       Package-Type: deb|udeb|type
246           This field defines the type of the package.  udeb is for size-
247           constrained packages used by the debian installer.  deb is the
248           default value, it is assumed if the field is absent.  More types
249           might be added in the future.
250
251       Architecture: arch|all|any (required)
252           The architecture specifies on which type of hardware this package
253           runs. For packages that run on all architectures, use the any
254           value. For packages that are architecture independent, such as
255           shell and Perl scripts or documentation, use the all value. To
256           restrict the packages to a certain set of architectures, specify
257           the architecture names, separated by a space. It's also possible to
258           put architecture wildcards in that list (see dpkg-architecture(1)
259           for more information about them).
260
261       Build-Profiles: restriction-formula
262           This field specifies the conditions for which this binary package
263           does or does not build.  To express that condition, the same
264           restriction formula syntax from the Build-Depends field is used.
265
266           If a binary package paragraph does not contain this field, then it
267           implicitly means that it builds with all build profiles (including
268           none at all).
269
270           In other words, if a binary package paragraph is annotated with a
271           non-empty Build-Profiles field, then this binary package is
272           generated if and only if the condition expressed by the conjunctive
273           normal form expression evaluates to true.
274
275       Protected: Byes|no
276       Essential: yes|no
277       Build-Essential: yes|no
278       Multi-Arch: same|foreign|allowed|no
279       Tag: tag-list
280       Description: short-description (recommended)
281           These fields are described in the deb-control(5) manual page, as
282           they are copied literally to the control file of the binary
283           package.
284
285       Depends: package-list
286       Pre-Depends: package-list
287       Recommends: package-list
288       Suggests: package-list
289       Breaks: package-list
290       Enhances: package-list
291       Replaces: package-list
292       Conflicts: package-list
293       Provides: package-list
294       Built-Using: package-list
295       Static-Built-Using: package-list
296           These fields declare relationships between packages. They are
297           discussed in the deb-control(5) manpage.  When these fields are
298           found in debian/control they can also end with a trailing comma
299           (since dpkg 1.10.14), have architecture specifications and
300           restriction formulas which will all get reduced when generating the
301           fields for deb-control(5).
302
303       Subarchitecture: value
304       Kernel-Version: value
305       Installer-Menu-Item: value
306           These fields are used by the debian-installer in udebs and are
307           usually not needed.  See
308           /usr/share/doc/debian-installer/devel/modules.txt from the debian-
309           installer package for more details about them.
310

USER-DEFINED FIELDS

312       It is allowed to add additional user-defined fields to the control
313       file. The tools will ignore these fields. If you want the fields to be
314       copied over to the output files, such as the binary packages, you need
315       to use a custom naming scheme: the fields should start with an X,
316       followed by zero or more of the letters SBC and a hyphen.
317
318       S   The field will appear in the source package control file, see
319           dsc(5).
320
321       B   The field will appear in the control file in the binary package,
322           see deb-control(5).
323
324       C   The field will appear in the upload control (.changes) file, see
325           deb-changes(5).
326
327       Note that the X[SBC]- prefixes are stripped when the fields are copied
328       over to the output files. A field XC-Approved-By will appear as
329       Approved-By in the changes file and will not appear in the binary or
330       source package control files.
331
332       Take into account that these user-defined fields will be using the
333       global namespace, which might at some point in the future collide with
334       officially recognized fields. To avoid such potential situation you can
335       prefix those fields with Private-, such as XB-Private-New-Field.
336

EXAMPLE

338        # Comment
339        Source: dpkg
340        Section: admin
341        Priority: required
342        Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
343        # this field is copied to the binary and source packages
344        XBS-Upstream-Release-Status: stable
345        Homepage: https://wiki.debian.org/Teams/Dpkg
346        Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git
347        Vcs-Git: https://git.dpkg.org/git/dpkg/dpkg.git
348        Standards-Version: 3.7.3
349        Build-Depends: pkg-config, debhelper (>= 4.1.81),
350         libselinux1-dev (>= 1.28-4) [!linux-any]
351
352        Package: dpkg-dev
353        Section: utils
354        Priority: optional
355        Architecture: all
356        # this is a custom field in the binary package
357        XB-Mentoring-Contact: Raphael Hertzog <hertzog@debian.org>
358        Depends: dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2),
359         bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl
360        Recommends: gcc | c-compiler, build-essential
361        Suggests: gnupg, debian-keyring
362        Conflicts: dpkg-cross (<< 2.0.0), devscripts (<< 2.10.26)
363        Replaces: manpages-pl (<= 20051117-1)
364        Description: Debian package development tools
365         This package provides the development tools (including dpkg-source)
366         required to unpack, build and upload Debian source packages.
367         .
368         Most Debian source packages will require additional tools to build;
369         for example, most packages need make and the C compiler gcc.
370

SEE ALSO

372       /usr/share/doc/dpkg/spec/rootless-builds.txt, deb822(5), deb-
373       control(5), deb-version(7), dpkg-source(1)
374
375
376
3771.21.9                            2022-07-01                deb-src-control(5)
Impressum