1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
About this manual
=================
.. _s1.1:
Scope
-----
This manual describes the policy requirements for the Debian
distribution. This includes the structure and contents of the Debian
archive and several design issues of the operating system, as well as
technical requirements that each package must satisfy to be included in
the distribution.
This manual also describes Debian policy as it relates to creating
Debian packages. It is not a tutorial on how to build packages, nor is
it exhaustive where it comes to describing the behavior of the
packaging system. Instead, this manual attempts to define the
interface to the package management system with which the developers
must be conversant. [#]_
The footnotes present in this manual are merely informative, and are not
part of Debian policy itself.
The appendices to this manual are not necessarily normative, either.
Please see :doc:`ap-pkg-scope` for more information.
In the normative part of this manual, the words *must*, *should* and
*may*, and the adjectives *required*, *recommended* and *optional*, are
used to distinguish the significance of the various guidelines in this
policy document. Packages that do not conform to the guidelines denoted
by *must* (or *required*) will generally not be considered acceptable
for the Debian distribution. Non-conformance with guidelines denoted by
*should* (or *recommended*) will generally be considered a bug, but will
not necessarily render a package unsuitable for distribution. Guidelines
denoted by *may* (or *optional*) are truly optional and adherence is
left to the maintainer's discretion.
These classifications are roughly equivalent to the bug severities
*serious* (for *must* or *required* directive violations), *minor*,
*normal* or *important* (for *should* or *recommended* directive
violations) and *wishlist* (for *optional* items). [#]_
Much of the information presented in this manual will be useful even
when building a package which is to be distributed in some other way or
is intended for local use only.
udebs (stripped-down binary packages used by the Debian Installer) do
not comply with all of the requirements discussed here. See the `Debian
Installer internals
manual <https://d-i.alioth.debian.org/doc/internals/ch03.html>`_ for
more information about them.
.. _s1.2:
New versions of this document
-----------------------------
This manual is distributed via the Debian package
`debian-policy <https://packages.debian.org/debian-policy>`_.
The current version of this document is also available from the Debian
web mirrors at https://www.debian.org/doc/debian-policy/. Also
available from the same directory are several other formats:
`policy.epub
<https://www.debian.org/doc/debian-policy/policy.epub>`_,
`policy.txt
<https://www.debian.org/doc/debian-policy/policy.txt>`_ and
`policy.pdf
<https://www.debian.org/doc/debian-policy/policy.pdf>`_. Included
in both the same directory and in the debian-policy package is a
standalone copy of :doc:`upgrading-checklist`, which indicates policy
changes between versions of this document.
.. _s-authors:
Authors and Maintainers
-----------------------
Early history
~~~~~~~~~~~~~
Originally called "Debian GNU/Linux Policy Manual", this manual was
initially written in 1996 by Ian Jackson. It was revised on November
27th, 1996 by David A. Morris. Christian Schwarz added new sections on
March 15th, 1997, and reworked/restructured it in April-July 1997.
Christoph Lameter contributed the "Web Standard". Julian Gilbey
largely restructured it in 2001. Since September 1998, changes to the
contents of this document have been co-ordinated by means of the
`debian-policy mailing list <mailto:debian-policy@lists.debian.org>`_
Current process
~~~~~~~~~~~~~~~
The Policy Editors are DPL delegates with responsibility for the
contents of this document (see the Debian Constitution for the meaning
of "DPL delegate"). However, the Policy Editors further delegate
their editorial power to a process of establishing project member
consensus on the debian-policy mailing list, as described in
:doc:`ap-process`. The current Policy Editors are:
1. Russ Allbery
2. Sean Whitton
Improvements
~~~~~~~~~~~~
While the authors of this document have tried hard to avoid typos and
other errors, these do still occur. If you discover an error in this
manual or if you want to give any comments, suggestions, or criticisms
please send an email to the Debian Policy Mailing List,
debian-policy@lists.debian.org, or submit a bug report against the
``debian-policy`` package.
Please do not try to reach the individual authors or maintainers of the
Policy Manual regarding changes to the Policy.
New techniques and functionality are generally implemented in the
Debian archive (long) before they are detailed in this document. This
is not considered to be a problem: there is a consensus in the Debian
Project that the task of keeping this document up-to-date should never
block making improvements to Debian. Nevertheless, it is better to
submit patches to this document sooner rather than later. This
reduces the amount of work that is needed on the part of others to get
themselves up-to-speed on new best practices.
.. _s-related:
Related documents
-----------------
There are several other documents other than this Policy Manual that are
necessary to fully understand some Debian policies and procedures.
The external "sub-policy" documents are referred to in:
- :ref:`s-fhs`
- :ref:`s-virtual-pkg`
- :ref:`s-menus`
- :ref:`s-perl`
- :ref:`s-maintscriptprompt`
- :ref:`s-emacs`
In addition to those, which carry the weight of policy, there is the
Debian Developer's Reference. This document describes procedures and
resources for Debian developers, but it is *not* normative; rather, it
includes things that don't belong in the Policy, such as best practices
for developers.
The Developer's Reference is available in the developers-reference
package. It's also available from the Debian web mirrors at
https://www.debian.org/doc/developers-reference/.
Finally, a :ref:`specification for machine-readable copyright files
<s-copyrightformat>` is maintained as part of the debian-policy
package using the same procedure as the other policy documents. Use of
this format is optional.
.. _s-definitions:
Definitions
-----------
The following terms are used in this Policy Manual:
ASCII
The character encoding specified by ANSI X3.4-1986 and its
predecessor standards, referred to in MIME as US-ASCII, and
corresponding to an encoding in eight bits per character of the
first 128 `Unicode <http://www.unicode.org/>`_ characters, with the
eighth bit always zero.
UTF-8
The transformation format (sometimes called encoding) of
`Unicode <http://www.unicode.org/>`_ defined by `RFC
3629 <https://www.rfc-editor.org/rfc/rfc3629.txt>`__. UTF-8 has the
useful property of having ASCII as a subset, so any text encoded in
ASCII is trivially also valid UTF-8.
.. [#]
Informally, the criteria used for inclusion is that the material meet
one of the following requirements:
Standard interfaces
The material presented represents an interface to the packaging
system that is mandated for use, and is used by, a significant
number of packages, and therefore should not be changed without
peer review. Package maintainers can then rely on this interface
not changing, and the package management software authors need to
ensure compatibility with this interface definition. (Control
file and changelog file formats are examples.)
Chosen Convention
If there are a number of technically viable choices that can be
made, but one needs to select one of these options for
inter-operability. The version number format is one example.
Please note that these are not mutually exclusive; selected
conventions often become parts of standard interfaces.
Translations
------------
When translations of this document into languages other than English
disagree with the English text, the English text takes precedence.
.. [#]
Compare RFC 2119. Note, however, that these words are used in a
different way in this document.
|
