<abstract>
This manual describes the policy requirements for the Debian
- GNU/Linux distribution. This includes the structure and
+ 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.
<p>
A copy of the GNU General Public License is available as
- <file>/usr/share/common-licenses/GPL</file> in the Debian GNU/Linux
+ <file>/usr/share/common-licenses/GPL</file> in the Debian
distribution or on the World Wide Web at
<url id="http://www.gnu.org/copyleft/gpl.html"
name="the GNU General Public Licence">. You can also
<heading>Scope</heading>
<p>
This manual describes the policy requirements for the Debian
- GNU/Linux distribution. This includes the structure and
+ 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
<heading>The Debian Archive</heading>
<p>
- The Debian GNU/Linux system is maintained and distributed as a
+ The Debian system is maintained and distributed as a
collection of <em>packages</em>. Since there are so many of
them (currently well over 15000), they are split into
<em>sections</em> and given <em>priorities</em> to simplify
</p>
<p>
- The <em>main</em> archive area forms the <em>Debian GNU/Linux
- distribution</em>.
+ The <em>main</em> archive area forms the <em>Debian distribution</em>.
</p>
<p>
<heading>Binary packages</heading>
<p>
- The Debian GNU/Linux distribution is based on the Debian
+ The Debian distribution is based on the Debian
package management system, called <prgn>dpkg</prgn>. Thus,
all packages in the Debian distribution must be provided
in the <tt>.deb</tt> file format.
</sect>
- <sect>
+ <sect id="maintainer">
<heading>The maintainer of a package</heading>
<p>
- Every package must have a Debian maintainer (the
- maintainer may be one person or a group of people
- reachable from a common email address, such as a mailing
- list). The maintainer is responsible for ensuring that
- the package is placed in the appropriate distributions.
- </p>
-
- <p>
- The maintainer must be specified in the
- <tt>Maintainer</tt> control field with their correct name
- and a working email address. If one person maintains
- several packages, they should try to avoid having
- different forms of their name and email address in
+ Every package must have a maintainer, except for orphaned
+ packages as described below. The maintainer may be one person
+ or a group of people reachable from a common email address, such
+ as a mailing list. The maintainer is responsible for
+ maintaining the Debian packaging files, evaluating and
+ responding appropriately to reported bugs, uploading new
+ versions of the package (either directly or through a sponsor),
+ ensuring that the package is placed in the appropriate archive
+ area and included in Debian releases as appropriate for the
+ stability and utility of the package, and requesting removal of
+ the package from the Debian distribution if it is no longer
+ useful or maintainable.
+ </p>
+
+ <p>
+ The maintainer must be specified in the <tt>Maintainer</tt>
+ control field with their correct name and a working email
+ address. The email address given in the <tt>Maintainer</tt>
+ control field must accept mail from those role accounts in
+ Debian used to send automated mails regarding the package. This
+ includes non-spam mail from the bug-tracking system, all mail
+ from the Debian archive maintenance software, and other role
+ accounts or automated processes that are commonly agreed on by
+ the project.<footnote>
+ A sample implementation of such a whitelist written for the
+ Mailman mailing list management software is used for mailing
+ lists hosted by alioth.debian.org.
+ </footnote>
+ If one person or team maintains several packages, they should
+ use the same form of their name and email address in
the <tt>Maintainer</tt> fields of those packages.
</p>
</p>
<p>
- If the maintainer of a package quits from the Debian
- project, "Debian QA Group"
- <email>packages@qa.debian.org</email> takes over the
- maintainer-ship of the package until someone else
- volunteers for that task. These packages are called
- <em>orphaned packages</em>.<footnote>
- The detailed procedure for doing this gracefully can
- be found in the Debian Developer's Reference,
- see <ref id="related">.
+ If the maintainer of the package is a team of people with a
+ shared email address, the <tt>Uploaders</tt> control field must
+ be present and must contain at least one human with their
+ personal email address. See <ref id="f-Uploaders"> for the
+ syntax of that field.
+ </p>
+
+ <p>
+ An orphaned package is one with no current maintainer. Orphaned
+ packages should have their <tt>Maintainer</tt> control field set
+ to <tt>Debian QA Group <packages@qa.debian.org></tt>.
+ These packages are considered maintained by the Debian project
+ as a whole until someone else volunteers to take over
+ maintenance.<footnote>
+ The detailed procedure for gracefully orphaning a package can
+ be found in the Debian Developer's Reference
+ (see <ref id="related">).
</footnote>
</p>
</sect>
<p>
Sometimes, unpacking one package requires that another package
be first unpacked <em>and</em> configured. In this case, the
- dependent package must specify this dependency in
+ depending package must specify this dependency in
the <tt>Pre-Depends</tt> control field.
</p>
<p>
The <tt>base system</tt> is a minimum subset of the Debian
- GNU/Linux system that is installed before everything else
+ system that is installed before everything else
on a new system. Only very few packages are allowed to form
part of the base system, in order to keep the required disk
usage very small.
identical behavior.
</p>
+ <p>
+ The following targets are required and must be implemented
+ by <file>debian/rules</file>: <tt>clean</tt>, <tt>binary</tt>,
+ <tt>binary-arch</tt>, <tt>binary-indep</tt>, and <tt>build</tt>.
+ These are the targets called by <prgn>dpkg-buildpackage</prgn>.
+ </p>
+
<p>
Since an interactive <file>debian/rules</file> script makes it
- impossible to auto-compile that package and also makes it
- hard for other people to reproduce the same binary
- package, all <em>required targets</em> must be
- non-interactive. At a minimum, required targets are the
- ones called by <prgn>dpkg-buildpackage</prgn>, namely,
- <em>clean</em>, <em>binary</em>, <em>binary-arch</em>,
- <em>binary-indep</em>, and <em>build</em>. It also follows
- that any target that these targets depend on must also be
+ impossible to auto-compile that package and also makes it hard
+ for other people to reproduce the same binary package, all
+ required targets must be non-interactive. It also follows that
+ any target that these targets depend on must also be
non-interactive.
</p>
<p>
- The targets are as follows (required unless stated otherwise):
+ The targets are as follows:
<taglist>
- <tag><tt>build</tt></tag>
+ <tag><tt>build</tt> (required)</tag>
<item>
<p>
The <tt>build</tt> target should perform all the
</p>
</item>
- <tag><tt>binary</tt>, <tt>binary-arch</tt>,
- <tt>binary-indep</tt>
+ <tag><tt>binary</tt> (required), <tt>binary-arch</tt>
+ (required), <tt>binary-indep</tt> (required)
</tag>
<item>
<p>
</p>
</item>
- <tag><tt>clean</tt></tag>
+ <tag><tt>clean</tt> (required)</tag>
<item>
<p>
This must undo any effects that the <tt>build</tt>
<p>
The architectures we build on and build for are determined
- by <prgn>make</prgn> variables using the utility
- <qref id="pkg-dpkg-architecture"><prgn>dpkg-architecture</prgn></qref>.
- You can determine the
- Debian architecture and the GNU style architecture
- specification string for the build machine (the machine type
- we are building on) as well as for the host machine (the
- machine type we are building for). Here is a list of
- supported <prgn>make</prgn> variables:
+ by <prgn>make</prgn> variables using the
+ utility <qref id="pkg-dpkg-architecture"><prgn>dpkg-architecture</prgn></qref>.
+ You can determine the Debian architecture and the GNU style
+ architecture specification string for the build architecture as
+ well as for the host architecture. The build architecture is
+ the architecture on which <file>debian/rules</file> is run and
+ the package build is performed. The host architecture is the
+ architecture on which the resulting package will be installed
+ and run. These are normally the same, but may be different in
+ the case of cross-compilation (building packages for one
+ architecture on machines of a different architecture).
+ </p>
+
+ <p>
+ Here is a list of supported <prgn>make</prgn> variables:
<list compact="compact">
<item>
<tt>DEB_*_ARCH</tt> (the Debian architecture)
<tt>DEB_*_GNU_TYPE</tt>)
</list>
where <tt>*</tt> is either <tt>BUILD</tt> for specification of
- the build machine or <tt>HOST</tt> for specification of the
- host machine.
+ the build architecture or <tt>HOST</tt> for specification of the
+ host architecture.
</p>
<p>
putting the name in round brackets and moving it to the
end, and bringing the email address forward).
</p>
+
+ <p>
+ See <ref id="maintainer"> for additional requirements and
+ information about package maintainers.
+ </p>
</sect1>
<sect1 id="f-Uploaders">
<heading><tt>Uploaders</tt></heading>
<p>
- List of the names and email addresses of co-maintainers of
- the package, if any. If the package has other maintainers
- beside the one named in the
- <qref id="f-Maintainer">Maintainer field</qref>, their names
- and email addresses should be listed here. The format of each
- entry is the same as that of the Maintainer field, and
- multiple entries must be comma separated. This is an optional
- field.
+ List of the names and email addresses of co-maintainers of the
+ package, if any. If the package has other maintainers besides
+ the one named in the <qref id="f-Maintainer">Maintainer
+ field</qref>, their names and email addresses should be listed
+ here. The format of each entry is the same as that of the
+ Maintainer field, and multiple entries must be comma
+ separated.
+ </p>
+
+ <p>
+ This is normally an optional field, but if
+ the <tt>Maintainer</tt> control field names a group of people
+ and a shared email address, the <tt>Uploaders</tt> field must
+ be present and must contain at least one human with their
+ personal email address.
</p>
<p>
the <prgn>preinst</prgn> script cannot rely on any files
included in its package. Only essential packages and
pre-dependencies (<tt>Pre-Depends</tt>) may be assumed to be
- available. Pre-dependencies will be at least unpacked.
- They may be only unpacked or "Half-Configured", not
- completely configured, but only if a previous version of the
- pre-dependency was completely configured and the
- pre-dependency had not been removed since then.
+ available. Pre-dependencies will have been configured at
+ least once, but at the time the <prgn>preinst</prgn> is
+ called they may only be in an unpacked or "Half-Configured"
+ state if a previous version of the pre-dependency was
+ completely configured and has not been removed since then.
</item>
<tag><var>old-preinst</var> <tt>abort-upgrade</tt>
The files contained in the package will be unpacked. All
package dependencies will at least be unpacked. If there
are no circular dependencies involved, all package
- dependencies will be configured.
+ dependencies will be configured. For behavior in the case
+ of circular dependencies, see the discussion
+ in <ref id="binarydeps">.
</item>
<tag><var>old-postinst</var> <tt>abort-upgrade</tt>
foo's <tt>postinst abort-remove</tt> would be called with
bar only "Half-Installed".
</footnote>
+ The <prgn>postinst</prgn> should still attempt any actions
+ for which its dependencies are required, since they will
+ normally be available, but consider the correct error
+ handling approach if those actions fail. Aborting
+ the <prgn>postinst</prgn> action if commands or facilities
+ from the package dependencies are not available is often the
+ best approach.
</item>
</taglist>
</p>
previously been deconfigured and only be unpacked, at which
point subsequent package changes do not consider its
dependencies. Therefore, all <prgn>postrm</prgn> actions
- may only rely on essential packages and cannot assume that
- the package's dependencies are available.
+ may only rely on essential packages and must gracefully skip
+ any actions that require the package's dependencies if those
+ dependencies are unavailable.<footnote>
+ This is often done by checking whether the command or
+ facility the <prgn>postrm</prgn> intends to call is
+ available before calling it. For example:
+<example>
+if [ "$1" = purge ] && [ -e /usr/share/debconf/confmodule ]; then
+ . /usr/share/debconf/confmodule
+ db_purge
+fi
+</example>
+ in <prgn>postrm</prgn> purges the <prgn>debconf</prgn>
+ configuration for the package
+ if <package>debconf</package> is installed.
+ </foonote>
</item>
<tag><var>new-postrm</var> <tt>failed-upgrade</tt>
broken at some point and the dependency requirements violated
for at least one package. Packages involved in circular
dependencies may not be able to rely on their dependencies being
- configured when being configured depending on which side of the
- break of the circular dependency loop they happen to be on. If
- one of the packages in the loop has no <prgn>postinst</prgn>
- script, then the cycle will be broken at that package; this
- ensures that all <prgn>postinst</prgn> scripts are run with
- their dependencies properly configured if this is possible.
- Otherwise the breaking point is arbitrary. Packages should
- therefore avoid circular dependencies where possible,
- particularly if they have <prgn>postinst</prgn> scripts.
+ configured before they themselves are configured, depending on
+ which side of the break of the circular dependency loop they
+ happen to be on. If one of the packages in the loop has
+ no <prgn>postinst</prgn> script, then the cycle will be broken
+ at that package; this ensures that all <prgn>postinst</prgn>
+ scripts are run with their dependencies properly configured if
+ this is possible. Otherwise the breaking point is arbitrary.
+ Packages should therefore avoid circular dependencies where
+ possible, particularly if they have <prgn>postinst</prgn>
+ scripts.
</p>
<p>
least unpacked, but they may be only "Half-Installed" if a
previous upgrade of the dependency failed.
</p>
+
+ <p>
+ Finally, the <tt>Depends</tt> field should be used if the
+ depended-on package is needed by the <prgn>postrm</prgn>
+ script to fully clean up after the package removal. There
+ is no guarantee that package dependencies will be
+ available when <prgn>postrm</prgn> is run, but the
+ depended-on package is more likely to be available if the
+ package declares a dependency (particularly in the case
+ of <tt>postrm remove</tt>). The <prgn>postrm</prgn>
+ script must gracefully skip actions that require a
+ dependency if that dependency isn't available.
+ </p>
</item>
<tag><tt>Recommends</tt></tag>
<p>
Packages in the <em>contrib</em> or <em>non-free</em> archive
areas should state in the copyright file that the package is not
- part of the Debian GNU/Linux distribution and briefly explain
- why.
+ part of the Debian distribution and briefly explain why.
</p>
<p>
<prgn>dpkg</prgn> is a suite of programs for creating binary
package files and installing and removing them on Unix
systems.<footnote>
- <prgn>dpkg</prgn> is targeted primarily at Debian
- GNU/Linux, but may work on or be ported to other
- systems.
+ <prgn>dpkg</prgn> is targeted primarily at Debian, but may
+ work on or be ported to other systems.
</footnote>
</p>
projects / debian / debian-policy.git / blobdiff