1deb-control(5) dpkg suite deb-control(5)
2
3
4
6 deb-control - Debian binary packages' master control file format
7
9 control
10
12 Each Debian binary package contains the master control file, which
13 contains a number of fields. Each field begins with a tag, such as
14 Package or Version (case insensitive), followed by a colon, and the
15 body of the field. Fields are delimited only by field tags. In other
16 words, field text may be multiple lines in length, but the installation
17 tools will generally join lines when processing the body of the field
18 (except in the case of the Description field, see below).
19
21 Package: package-name (required)
22 The value of this field determines the package name, and is used
23 to generate file names by most installation tools.
24
25 Version: version-string (required)
26 Typically, this is the original package's version number in
27 whatever form the program's author uses. It may also include a
28 Debian revision number (for non-native packages). The exact
29 format and sorting algorithm are described in deb-version(5).
30
31 Maintainer: fullname-email (recommended)
32 Should be in the format “Joe Bloggs <jbloggs@foo.com>”, and is
33 typically the person who created the package, as opposed to the
34 author of the software that was packaged.
35
36 Description: short-description (recommended)
37 long-description
38 The format for the package description is a short brief summary
39 on the first line (after the Description field). The following
40 lines should be used as a longer, more detailed description.
41 Each line of the long description must be preceded by a space,
42 and blank lines in the long description must contain a single
43 ‘.’ following the preceding space.
44
45 Section: section
46 This is a general field that gives the package a category based
47 on the software that it installs. Some common sections are
48 utils, net, mail, text, x11, etc.
49
50 Priority: priority
51 Sets the importance of this package in relation to the system as
52 a whole. Common priorities are required, standard, optional,
53 extra, etc.
54
55 The Section and Priority fields usually have a defined set of accepted
56 values based on the specific distribution policy.
57
58 Installed-Size: size
59 The approximate total size of the package's installed files, in
60 KiB units.
61
62 Essential: yes|no
63 This field is usually only needed when the answer is yes. It
64 denotes a package that is required for proper operation of the
65 system. Dpkg or any other installation tool will not allow an
66 Essential package to be removed (at least not without using one
67 of the force options).
68
69 Build-Essential: yes|no
70 This field is usually only needed when the answer is yes, and is
71 commonly injected by the archive software. It denotes a package
72 that is required when building other packages.
73
74 Architecture: arch|all (recommended)
75 The architecture specifies which type of hardware this package
76 was compiled for. Common architectures are amd64, armel, i386,
77 powerpc, etc. Note that the all value is meant for packages
78 that are architecture independent. Some examples of this are
79 shell and Perl scripts, and documentation.
80
81 Origin: name
82 The name of the distribution this package is originating from.
83
84 Bugs: url
85 The url of the bug tracking system for this package. The current
86 used format is bts-type://bts-address, like
87 debbugs://bugs.debian.org.
88
89 Homepage: url
90 The upstream project home page url.
91
92 Tag: tag-list
93 List of tags describing the qualities of the package. The
94 description and list of supported tags can be found in the
95 debtags package.
96
97 Multi-Arch: no|same|foreign|allowed
98 This field is used to indicate how this package should behave on
99 a multi-arch installations.
100
101 no This value is the default when the field is omitted, in
102 which case adding the field with an explicit no value is
103 generally not needed.
104
105 same This package is co-installable with itself, but it must
106 not be used to satisfy the dependency of any package of a
107 different architecture from itself.
108
109 foreign
110 This package is not co-installable with itself, but
111 should be allowed to satisfy a non-arch-qualified
112 dependency of a package of a different arch from itself
113 (if a dependency has an explicit arch-qualifier then the
114 value foreign is ignored).
115
116 allowed
117 This allows reverse-dependencies to indicate in their
118 Depends field that they accept this package from a
119 foreign architecture by qualifying the package name with
120 :any, but has no effect otherwise.
121
122 Source: source-name [(source-version)]
123 The name of the source package that this binary package came
124 from, if it is different than the name of the package itself.
125 If the source version differs from the binary version, then the
126 source-name will be followed by a source-version in parenthesis.
127 This can happen for example on a binary-only non-maintainer
128 upload, or when setting a different binary version via
129 «dpkg-gencontrol -v».
130
131 Subarchitecture: value
132 Kernel-Version: value
133 Installer-Menu-Item: value
134 These fields are used by the debian-installer and are usually
135 not needed. See
136 /usr/share/doc/debian-installer/devel/modules.txt from the
137 debian-installer package for more details about them.
138
139
140 Depends: package-list
141 List of packages that are required for this package to provide a
142 non-trivial amount of functionality. The package maintenance
143 software will not allow a package to be installed if the
144 packages listed in its Depends field aren't installed (at least
145 not without using the force options). In an installation, the
146 postinst scripts of packages listed in Depends fields are run
147 before those of the packages which depend on them. On the
148 opposite, in a removal, the prerm script of a package is run
149 before those of the packages listed in its Depends field.
150
151 Pre-Depends: package-list
152 List of packages that must be installed and configured before
153 this one can be installed. This is usually used in the case
154 where this package requires another package for running its
155 preinst script.
156
157 Recommends: package-list
158 Lists packages that would be found together with this one in all
159 but unusual installations. The package maintenance software will
160 warn the user if they install a package without those listed in
161 its Recommends field.
162
163 Suggests: package-list
164 Lists packages that are related to this one and can perhaps
165 enhance its usefulness, but without which installing this
166 package is perfectly reasonable.
167
168 The syntax of Depends, Pre-Depends, Recommends and Suggests fields is a
169 list of groups of alternative packages. Each group is a list of
170 packages separated by vertical bar (or “pipe”) symbols, ‘|’. The
171 groups are separated by commas. Commas are to be read as “AND”, and
172 pipes as “OR”, with pipes binding more tightly. Each package name is
173 optionally followed by an architecture qualifier appended after a colon
174 ‘:’, optionally followed by a version number specification in
175 parentheses.
176
177 An architecture qualifier name can be a real Debian architecture name
178 (since dpkg 1.16.5) or any (since dpkg 1.16.2). If omitted, the
179 default is the current binary package architecture. A real Debian
180 architecture name will match exactly that architecture for that package
181 name, any will match any architecture for that package name if the
182 package has been marked as Multi-Arch: allowed.
183
184 A version number may start with a ‘>>’, in which case any later version
185 will match, and may specify or omit the Debian packaging revision
186 (separated by a hyphen). Accepted version relationships are ‘>>’ for
187 greater than, ‘<<’ for less than, ‘>=’ for greater than or equal to,
188 ‘<=’ for less than or equal to, and ‘=’ for equal to.
189
190 Breaks: package-list
191 Lists packages that this one breaks, for example by exposing
192 bugs when the named packages rely on this one. The package
193 maintenance software will not allow broken packages to be
194 configured; generally the resolution is to upgrade the packages
195 named in a Breaks field.
196
197 Conflicts: package-list
198 Lists packages that conflict with this one, for example by
199 containing files with the same names. The package maintenance
200 software will not allow conflicting packages to be installed at
201 the same time. Two conflicting packages should each include a
202 Conflicts line mentioning the other.
203
204 Replaces: package-list
205 List of packages files from which this one replaces. This is
206 used for allowing this package to overwrite the files of another
207 package and is usually used with the Conflicts field to force
208 removal of the other package, if this one also has the same
209 files as the conflicted package.
210
211 The syntax of Breaks, Conflicts and Replaces is a list of package
212 names, separated by commas (and optional whitespace). In the Breaks
213 and Conflicts fields, the comma should be read as “OR”. An optional
214 architecture qualifier can also be appended to the package name with
215 the same syntax as above, but the default is any instead of the binary
216 package architecture. An optional version can also be given with the
217 same syntax as above for the Breaks, Conflicts and Replaces fields.
218
219 Provides: package-list
220 This is a list of virtual packages that this one provides.
221 Usually this is used in the case of several packages all
222 providing the same service. For example, sendmail and exim can
223 serve as a mail server, so they provide a common package
224 (“mail-transport-agent”) on which other packages can depend.
225 This will allow sendmail or exim to serve as a valid option to
226 satisfy the dependency. This prevents the packages that depend
227 on a mail server from having to know the package names for all
228 of them, and using ‘|’ to separate the list.
229
230 The syntax of Provides is a list of package names, separated by commas
231 (and optional whitespace). An optional architecture qualifier can also
232 be appended to the package name with the same syntax as above. If
233 omitted, the default is the current binary package architecture. An
234 optional exact (equal to) version can also be given with the same
235 syntax as above (honored since dpkg 1.17.11).
236
237 Built-Using: package-list
238 This field lists extra source packages that were used during the
239 build of this binary package. This is an indication to the
240 archive maintenance software that these extra source packages
241 must be kept whilst this binary package is maintained. This
242 field must be a list of source package names with strict ‘=’
243 version relationships. Note that the archive maintenance
244 software is likely to refuse to accept an upload which declares
245 a Built-Using relationship which cannot be satisfied within the
246 archive.
247
248 Built-For-Profiles: profile-list (obsolete)
249 This field used to specify a whitespace separated list of build
250 profiles that this binary packages was built with (since dpkg
251 1.17.2 until 1.18.18). The information previously found in this
252 field can now be found in the .buildinfo file, which supersedes
253 it.
254
255 Auto-Built-Package: reason-list
256 This field specifies a whitespace separated list of reasons why
257 this package was auto-generated. Binary packages marked with
258 this field will not appear in the debian/control master source
259 control file. The only currently used reason is debug-symbols.
260
262 # Comment
263 Package: grep
264 Essential: yes
265 Priority: required
266 Section: base
267 Maintainer: Wichert Akkerman <wakkerma@debian.org>
268 Architecture: sparc
269 Version: 2.4-1
270 Pre-Depends: libc6 (>= 2.0.105)
271 Provides: rgrep
272 Conflicts: rgrep
273 Description: GNU grep, egrep and fgrep.
274 The GNU family of grep utilities may be the "fastest grep in the west".
275 GNU grep is based on a fast lazy-state deterministic matcher (about
276 twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
277 search for a fixed string that eliminates impossible text from being
278 considered by the full regexp matcher without necessarily having to
279 look at every character. The result is typically many times faster
280 than Unix grep or egrep. (Regular expressions containing backreferencing
281 will run more slowly, however).
282
284 deb(5), deb-version(5), debtags(1), dpkg(1), dpkg-deb(1).
285
286
287
2881.18.25 2018-06-26 deb-control(5)