1. About this manual¶
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. 1
This manual cannot and does not prohibit every possible bug or undesirable behaviour. The fact that something is not forbidden by Debian policy does not mean that it is not a bug, let alone that it is desirable. Questions not covered by policy should be evaluated on their merits.
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 Introduction and scope of these appendices 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). 2
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 for more information about them.
1.2. New versions of this document¶
This manual is distributed via the Debian package 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, policy.txt and policy.pdf. Included in both the same directory and in the debian-policy package is a standalone copy of Upgrading checklist, which indicates policy changes between versions of this document.
The following terms are used in this Policy Manual:
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 characters, with the eighth bit always zero.
The transformation format (sometimes called encoding) of Unicode defined by RFC 3629. 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.