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