1deb-src-control(5) dpkg suite deb-src-control(5)
2
6 deb-src-control - Debian source packages' master control file format
7
9 debian/control
10
12 Each Debian source package contains the master «control» file, which
13 contains at least 2 paragraphs, separated by a blank line. The first
14 paragraph lists all information about the source package in general,
15 while each following paragraph describes exactly one binary package.
16 Each paragraph consists of at least one field. A field starts with a
17 fieldname, such as Package or Section (case insensitive), followed by a
18 colon, the body of the field and a newline. Multi-line fields are also
19 allowed, but each supplementary line, without a fieldname, should start
20 with at least one space. The content of the multi-line fields is
21 generally joined to a single line by the tools (except in the case of
22 the Description field, see below). To insert empty lines into a multi-
23 line field, insert a dot after the space. Lines starting with a ‘#’
24 are treated as comments.
25
27 Source: source-package-name (required)
28 The value of this field is the name of the source package, and
29 should match the name of the source package in the
30 debian/changelog file. A package name must consist only of
31 lowercase letters (a-z), digits (0-9), plus (+) and minus (-)
32 signs, and periods (.). Package names must be at least two
33 characters long and must start with a lowercase alphanumeric
34 character (a-z0-9).
35 Maintainer: fullname-email (recommended)
38 Should be in the format «Joe Bloggs <jbloggs@foo.com>», and
39 references the person who currently maintains the package, as
40 opposed to the author of the software or the original packager.
41 Uploaders: fullname-email
44 Lists all the names and email addresses of co-maintainers of the
45 package, in the same format as the Maintainer field. Multiple
46 co-maintainers should be separated by a comma.
47 Standards-Version: version-string
50 This documents the most recent version of the distribution
51 policy standards this package complies with.
52 Description short-description
55 long-description
56 The format for the source package description is a short brief
57 summary on the first line (after the Description field). The
58 following lines should be used as a longer, more detailed
59 description. Each line of the long description must be preceded
60 by a space, and blank lines in the long description must contain
61 a single ‘.’ following the preceding space.
62 Homepage: url
65 The upstream project home page URL.
66 Bugs: url
69 The url of the bug tracking system for this package. The current
70 used format is bts-type://bts-address, like
71 debbugs://bugs.debian.org. This field is usually not needed.
72 Rules-Requires-Root: no|binary-targets|impl-keywords
75 This field is used to indicate whether the debian/rules file
76 requires (fake)root privileges to run some of its targets, and
77 if so when.
78 no The binary targets will not require (fake)root at all.
80 binary-targets
82 The binary targets must always be run under (fake)root.
83 This value is the default when the field is omitted;
84 adding the field with an explicit binary-targets while
85 not strictly needed, marks it as having been analyzed for
86 this requirement.
87 impl-keywords
89 This is a space-separated list of keywords which define
90 when (fake)root is required.
91 Keywords consist of namespace/cases. The namespace part
93 cannot contain "/" or whitespace. The cases part cannot
94 contain whitespace. Furthermore, both parts must consist
95 entirely of printable ASCII characters.
96 Each tool/package will define a namespace named after
98 itself and provide a number of cases where (fake)root is
99 required. (See "Implementation provided keywords" in
100 rootless-builds.txt).
101 When the field is set to one of the impl-keywords, the
103 builder will expose an interface that is used to run a
104 command under (fake)root. (See "Gain Root API" in
105 rootless-builds.txt.)
106 Testsuite: name-list
109 Testsuite-Triggers: package-list
110 These fields are described in the dsc(5) manual page, as they
111 are generated from information inferred from
112 debian/tests/control or copied literally to the source control
113 file.
114 Vcs-Arch: url
117 Vcs-Bzr: url
118 Vcs-Cvs: url
119 Vcs-Darcs: url
120 Vcs-Git: url
121 Vcs-Hg: url
122 Vcs-Mtn: url
123 Vcs-Svn: url
124 The url of the Version Control System repository used to
125 maintain this package. Currently supported are Arch, Bzr
126 (Bazaar), Cvs, Darcs, Git, Hg (Mercurial), Mtn (Monotone) and
127 Svn (Subversion). Usually this field points to the latest
128 version of the package, such as the main branch or the trunk.
129 Vcs-Browser: url
132 The url of a webinterface to browse the Version Control System
133 repository.
134 Origin: name
137 The name of the distribution this package is originating from.
138 This field is usually not needed.
139 Section: section
142 This is a general field that gives the package a category based
143 on the software that it installs. Some common sections are
144 utils, net, mail, text, x11, etc.
145 Priority: priority
148 Sets the importance of this package in relation to the system as
149 a whole. Common priorities are required, standard, optional,
150 extra, etc.
151 The Section and Priority fields usually have a defined set of
153 accepted values based on the specific distribution policy.
154 Build-Depends: package-list
157 A list of packages that need to be installed and configured to
158 be able to build from source package. These dependencies need
159 to be satisfied when building binary architecture dependent or
160 independent packages and source packages. Including a
161 dependency in this field does not have the exact same effect as
162 including it in both Build-Depends-Arch and Build-Depends-Indep,
163 because the dependency also needs to be satisfied when building
164 the source package.
165 Build-Depends-Arch: package-list
167 Same as Build-Depends, but they are only needed when building
168 the architecture dependent packages. The Build-Depends are also
169 installed in this case. This field is supported since dpkg
170 1.16.4; in order to build with older dpkg versions,
171 Build-Depends should be used instead.
172 Build-Depends-Indep: package-list
175 Same as Build-Depends, but they are only needed when building
176 the architecture independent packages. The Build-Depends are
177 also installed in this case.
178 Build-Conflicts: package-list
181 A list of packages that should not be installed when the package
182 is built, for example because they interfere with the build
183 system used. Including a dependency in this list has the same
184 effect as including it in both Build-Conflicts-Arch and
185 Build-Conflicts-Indep, with the additional effect of being used
186 for source-only builds.
187 Build-Conflicts-Arch: package-list
190 Same as Build-Conflicts, but only when building the architecture
191 dependent packages. This field is supported since dpkg 1.16.4;
192 in order to build with older dpkg versions, Build-Conflicts
193 should be used instead.
194 Build-Conflicts-Indep: package-list
197 Same as Build-Conflicts, but only when building the architecture
198 independent packages.
199 The syntax of the Build-Depends, Build-Depends-Arch and
202 Build-Depends-Indep fields is a list of groups of alternative packages.
203 Each group is a list of packages separated by vertical bar (or “pipe”)
204 symbols, ‘|’. The groups are separated by commas ‘,’, and can end with
205 a trailing comma that will be eliminated when generating the fields for
206 deb-control(5) (since dpkg 1.10.14). Commas are to be read as “AND”,
207 and pipes as “OR”, with pipes binding more tightly. Each package name
208 is optionally followed by an architecture qualifier appended after a
209 colon ‘:’, optionally followed by a version number specification in
210 parentheses ‘(’ and ‘)’, an architecture specification in square
211 brackets ‘[’ and ‘]’, and a restriction formula consisting of one or
212 more lists of profile names in angle brackets ‘<’ and ‘>’.
213 The syntax of the Build-Conflicts, Build-Conflicts-Arch and
215 Build-Conflicts-Indep fields is a list of comma-separated package
216 names, where the comma is read as an “AND”, and where the list can end
217 with a trailing comma that will be eliminated when generating the
218 fields for deb-control(5) (since dpkg 1.10.14). Specifying alternative
219 packages using a “pipe” is not supported. Each package name is
220 optionally followed by a version number specification in parentheses,
221 an architecture specification in square brackets, and a restriction
222 formula consisting of one or more lists of profile names in angle
223 brackets.
224 An architecture qualifier name can be a real Debian architecture name
226 (since dpkg 1.16.5), any (since dpkg 1.16.2) or native (since dpkg
227 1.16.5). If omitted, the default for Build-Depends fields is the
228 current host architecture, the default for Build-Conflicts fields is
229 any. A real Debian architecture name will match exactly that
230 architecture for that package name, any will match any architecture for
231 that package name if the package is marked with Multi-Arch: allowed,
232 and native will match the current build architecture if the package is
233 not marked with Multi-Arch: foreign.
234 A version number may start with a ‘>>’, in which case any later version
236 will match, and may specify or omit the Debian packaging revision
237 (separated by a hyphen). Accepted version relationships are ‘>>’ for
238 greater than, ‘<<’ for less than, ‘>=’ for greater than or equal to,
239 ‘<=’ for less than or equal to, and ‘=’ for equal to.
240 An architecture specification consists of one or more architecture
242 names, separated by whitespace. Exclamation marks may be prepended to
243 each of the names, meaning “NOT”.
244 A restriction formula consists of one or more restriction lists,
246 separated by whitespace. Each restriction list is enclosed in angle
247 brackets. Items in the restriction list are build profile names,
248 separated by whitespace and can be prefixed with an exclamation mark,
249 meaning “NOT”. A restriction formula represents a disjunctive normal
250 form expression.
251 Note that dependencies on packages in the build-essential set can be
253 omitted and that declaring build conflicts against them is impossible.
254 A list of these packages is in the build-essential package.
255
259 Note that the Priority, Section and Homepage fields can also be in a
260 binary paragraph to override the global value from the source package.
261 Package: binary-package-name (required)
264 This field is used to name the binary package name. The same
265 restrictions as to a source package name apply.
266 Package-Type: deb|udeb|type
269 This field defines the type of the package. udeb is for size-
270 constrained packages used by the debian installer. deb is the
271 default value, it is assumed if the field is absent. More types
272 might be added in the future.
273 Architecture: arch|all|any (required)
276 The architecture specifies on which type of hardware this
277 package runs. For packages that run on all architectures, use
278 the any value. For packages that are architecture independent,
279 such as shell and Perl scripts or documentation, use the all
280 value. To restrict the packages to a certain set of
281 architectures, specify the architecture names, separated by a
282 space. It's also possible to put architecture wildcards in that
283 list (see dpkg-architecture(1) for more information about them).
284 Build-Profiles: restriction-formula
287 This field specifies the conditions for which this binary
288 package does or does not build. To express that condition, the
289 same restriction formula syntax from the Build-Depends field is
290 used.
291 If a binary package paragraph does not contain this field, then
293 it implicitly means that it builds with all build profiles
294 (including none at all).
295 In other words, if a binary package paragraph is annotated with
297 a non-empty Build-Profiles field, then this binary package is
298 generated if and only if the condition expressed by the
299 conjunctive normal form expression evaluates to true.
300 Essential: yes|no
303 Build-Essential: yes|no
304 Multi-Arch: same|foreign|allowed|no
305 Tag: tag-list
306 Description: short-description (recommended)
307 These fields are described in the deb-control(5) manual page, as
308 they are copied literally to the control file of the binary
309 package.
310 Depends: package-list
313 Pre-Depends: package-list
314 Recommends: package-list
315 Suggests: package-list
316 Breaks: package-list
317 Enhances: package-list
318 Replaces: package-list
319 Conflicts: package-list
320 Provides: package-list
321 Built-Using: package-list
322 These fields declare relationships between packages. They are
323 discussed in the deb-control(5) manpage. When these fields are
324 found in debian/control they can also end with a trailing comma
325 (since dpkg 1.10.14), have architecture specifications and
326 restriction formulas which will all get reduced when generating
327 the fields for deb-control(5).
328 Subarchitecture: value
331 Kernel-Version: value
332 Installer-Menu-Item: value
333 These fields are used by the debian-installer in udebs and are
334 usually not needed. See
335 /usr/share/doc/debian-installer/devel/modules.txt from the
336 debian-installer package for more details about them.
337
340 It is allowed to add additional user-defined fields to the control
341 file. The tools will ignore these fields. If you want the fields to be
342 copied over to the output files, such as the binary packages, you need
343 to use a custom naming scheme: the fields should start with an X,
344 followed by zero or more of the letters SBC and a hyphen.
345 S The field will appear in the source package control file, see
348 dsc(5).
349 B The field will appear in the control file in the binary package,
351 see deb-control(5).
352 C The field will appear in the upload control (.changes) file, see
354 deb-changes(5).
355 Note that the X[SBC]- prefixes are stripped when the fields are copied
358 over to the output files. A field XC-Approved-By will appear as
359 Approved-By in the changes file and will not appear in the binary or
360 source package control files.
361 Take into account that these user-defined fields will be using the
363 global namespace, which might at some point in the future collide with
364 officially recognized fields. To avoid such potential situation you can
365 prefix those fields with Private-, such as XB-Private-New-Field.
366
369 # Comment
370 Source: dpkg
371 Section: admin
372 Priority: required
373 Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
374 # this field is copied to the binary and source packages
375 XBS-Upstream-Release-Status: stable
376 Homepage: https://wiki.debian.org/Teams/Dpkg
377 Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git
378 Vcs-Git: https://git.dpkg.org/git/dpkg/dpkg.git
379 Standards-Version: 3.7.3
380 Build-Depends: pkg-config, debhelper (>= 4.1.81),
381 libselinux1-dev (>= 1.28-4) [!linux-any]
382 Package: dpkg-dev
384 Section: utils
385 Priority: optional
386 Architecture: all
387 # this is a custom field in the binary package
388 XB-Mentoring-Contact: Raphael Hertzog <hertzog@debian.org>
389 Depends: dpkg (>= 1.14.6), perl5, perl-modules, cpio (>= 2.4.2-2),
390 bzip2, lzma, patch (>= 2.2-1), make, binutils, libtimedate-perl
391 Recommends: gcc | c-compiler, build-essential
392 Suggests: gnupg, debian-keyring
393 Conflicts: dpkg-cross (<< 2.0.0), devscripts (<< 2.10.26)
394 Replaces: manpages-pl (<= 20051117-1)
395 Description: Debian package development tools
396 This package provides the development tools (including dpkg-source)
397 required to unpack, build and upload Debian source packages.
398 .
399 Most Debian source packages will require additional tools to build;
400 for example, most packages need make and the C compiler gcc.
401
405 deb-control(5), deb-version(7), dpkg-source(1)
4061.19.7 2019-06-03 deb-src-control(5)