1deb-control(5) Debian deb-control(5)
2
3
4
6 deb-control - Debian packages' master control file format
7
9 control
10
12 Each Debian package contains the master `control' file, which contains
13 a number of fields, or comments when the line starts with '#'. Each
14 field begins with a tag, such as Package or Version (case insensitive),
15 followed by a colon, and the body of the field. Fields are delimited
16 only by field tags. In other words, field text may be multiple lines in
17 length, but the installation tools will generally join lines when pro‐
18 cessing the body of the field (except in the case of the Description
19 field, see below).
20
22 Package: <package name>
23 The value of this field determines the package name, and is used
24 to generate file names by most installation tools.
25
26 Version: <version string>
27 Typically, this is the original package's version number in
28 whatever form the program's author uses. It may also include a
29 Debian revision number (for non-native packages). The exact for‐
30 mat and sorting algorithm are described in deb-version(5).
31
32 Maintainer: <fullname email>
33 Should be in the format `Joe Bloggs <jbloggs@foo.com>', and is
34 typically the person who created the package, as opposed to the
35 author of the software that was packaged.
36
37 Description: <short description>
38 <long description>
39 The format for the package description is a short brief summary
40 on the first line (after the "Description" field). The following
41 lines should be used as a longer, more detailed description.
42 Each line of the long description must be preceded by a space,
43 and blank lines in the long description must contain a single
44 '.' following the preceding space.
45
47 Section: <section>
48 This is a general field that gives the package a category based
49 on the software that it installs. Some common sections are
50 `utils', `net', `mail', `text', `x11' etc.
51
52 Priority: <priority>
53 Sets the importance of this package in relation to the system as
54 a whole. Common priorities are `required', `standard',
55 `optional', `extra' etc.
56
57 In Debian, the Section and Priority fields have a defined set of
58 accepted values based on the Policy Manual. A list of these values can
59 be obtained from the latest version of the debian-policy package.
60
61 Essential: <yes|no>
62 This field is usually only needed when the answer is `yes'. It
63 denotes a package that is required for proper operation of the
64 system. Dpkg or any other installation tool will not allow an
65 Essential package to be removed (at least not without using one
66 of the force options).
67
68 Architecture: <arch|all>
69 The architecture specifies which type of hardware this package
70 was compiled for. Common architectures are `i386', `m68k',
71 `sparc', `alpha', `powerpc' etc. Note that the all option is
72 meant for packages that are architecture independent. Some exam‐
73 ples of this are shell and Perl scripts, and documentation.
74
75 Origin: <name>
76 The name of the distribution this package is originating from.
77
78 Bugs: <url>
79 The url of the bug tracking system for this package. The current
80 used format is <bts_type>://<bts_address>, like deb‐
81 bugs://bugs.debian.org.
82
83 Homepage: <url>
84 The upstream project home page URL.
85
86 Tag: <tag list>
87 List of tags describing the qualities of the package. The
88 description and list of supported tags can be found in the deb‐
89 tags package.
90
91 Source: <source name>
92 The name of the source package that this binary package came
93 from, if different than the name of the package itself.
94
95 Depends: <package list>
96 List of packages that are required for this package to provide a
97 non-trivial amount of functionality. The package maintenance
98 software will not allow a package to be installed if the pack‐
99 ages listed in its Depends field aren't installed (at least not
100 without using the force options). In an installation, the
101 postinst scripts of packages listed in Depends: fields are run
102 before those of the packages which depend on them. On the oppo‐
103 site, in a removal, the prerm script of a package is run before
104 those of the packages listed in its Depends: field.
105
106 Pre-Depends: <package list>
107 List of packages that must be installed and configured before
108 this one can be installed. This is usually used in the case
109 where this package requires another package for running its pre‐
110 inst script.
111
112 Recommends: <package list>
113 Lists packages that would be found together with this one in all
114 but unusual installations. The package maintenance software will
115 warn the user if they install a package without those listed in
116 its Recommends field.
117
118 Suggests: <package list>
119 Lists packages that are related to this one and can perhaps
120 enhance its usefulness, but without which installing this pack‐
121 age is perfectly reasonable.
122
123 The syntax of Depends, Pre-Depends, Recommends and Suggests fields is a
124 list of groups of alternative packages. Each group is a list of pack‐
125 ages separated by vertical bar (or `pipe') symbols, `|'. The groups are
126 separated by commas. Commas are to be read as `AND', and pipes as `OR',
127 with pipes binding more tightly. Each package name is optionally fol‐
128 lowed by a version number specification in parentheses.
129
130 A version number may start with a `>>', in which case any later version
131 will match, and may specify or omit the Debian packaging revision (sep‐
132 arated by a hyphen). Accepted version relationships are ">>" for
133 greater than, "<<" for less than, ">=" for greater than or equal to,
134 "<=" for less than or equal to, and "=" for equal to.
135
136 Breaks: <package list>
137 Lists packages that this one breaks, for example by exposing
138 bugs when the named packages rely on this one. The package main‐
139 tenance software will not allow broken packages to be config‐
140 ured; generally the resolution is to upgrade the packages named
141 in a Breaks field.
142
143 Conflicts: <package list>
144 Lists packages that conflict with this one, for example by con‐
145 taining files with the same names. The package maintenance soft‐
146 ware will not allow conflicting packages to be installed at the
147 same time. Two conflicting packages should each include a Con‐
148 flicts line mentioning the other.
149
150 Replaces: <package list>
151 List of packages files from which this one replaces. This is
152 used for allowing this package to overwrite the files of another
153 package and is usually used with the Conflicts field to force
154 removal of the other package, if this one also has the same
155 files as the conflicted package.
156
157 Provides: <package list>
158 This is a list of virtual packages that this one provides. Usu‐
159 ally this is used in the case of several packages all providing
160 the same service. For example, sendmail and exim can serve as a
161 mail server, so they provide a common package (`mail-transport-
162 agent') on which other packages can depend. This will allow
163 sendmail or exim to serve as a valid option to satisfy the
164 dependency. This prevents the packages that depend on a mail
165 server from having to know the package names for all of them,
166 and using `|' to separate the list.
167
168 The syntax of Conflicts, Replaces and Provides is a list of package
169 names, separated by commas (and optional whitespace). In the Conflicts
170 field, the comma should be read as `OR'. An optional version can also
171 be given with the same syntax as above for the Conflicts and Replaces
172 fields.
173
175 # Comment
176 Package: grep
177 Essential: yes
178 Priority: required
179 Section: base
180 Maintainer: Wichert Akkerman <wakkerma@debian.org>
181 Architecture: sparc
182 Version: 2.4-1
183 Pre-Depends: libc6 (>= 2.0.105)
184 Provides: rgrep
185 Conflicts: rgrep
186 Description: GNU grep, egrep and fgrep.
187 The GNU family of grep utilities may be the "fastest grep in the west".
188 GNU grep is based on a fast lazy-state deterministic matcher (about
189 twice as fast as stock Unix egrep) hybridized with a Boyer-Moore-Gosper
190 search for a fixed string that eliminates impossible text from being
191 considered by the full regexp matcher without necessarily having to
192 look at every character. The result is typically many times faster
193 than Unix grep or egrep. (Regular expressions containing backreferencing
194 will run more slowly, however).
195
197 deb(5), deb-version(5), debtags(1), dpkg(1), dpkg-deb(1).
198
199
200
201Debian Project 2007-10-08 deb-control(5)