<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.
<heading>The maintainer of a package</heading>
<p>
- Every package must have a 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 maintaining the Debian packaging files, evaluating and
+ 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
</p>
<p>
- If the maintainer of a package no longer has time or desire to
- maintain a package, it should be orphaned according to the
- procedure described in the Debian Developer's Reference
- (see <ref id="related">). The maintainer then
- becomes <tt>Debian QA Group <packages@qa.debian.org></tt>.
+ 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.
+ 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>
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.
The maintainer name and email address used in the changelog
should be the details of the person uploading <em>this</em>
version. They are <em>not</em> necessarily those of the
- usual package maintainer. The information here will be
- copied to the <tt>Changed-By</tt> field in the
- <tt>.changes</tt> file (see <ref id="f-Changed-By">),
- and then later used to send an acknowledgement when the
- upload has been installed.
+ usual package maintainer.<footnote>
+ If the developer uploading the package is not one of the usual
+ maintainers of the package (as listed in
+ the <qref id="f-Maintainer"><tt>Maintainer</tt></qref>
+ or <qref id="f-Uploaders"><tt>Uploaders</tt></qref> control
+ fields of the package), the first line of the changelog is
+ conventionally used to explain why a non-maintainer is
+ uploading the package. The Debian Developer's Reference
+ (see <ref id="related">) documents the conventions
+ used.</footnote>
+ The information here will be copied to the <tt>Changed-By</tt>
+ field in the <tt>.changes</tt> file
+ (see <ref id="f-Changed-By">), and then later used to send an
+ acknowledgement when the upload has been installed.
</p>
<p>
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>
library directories of the dynamic linker (which are currently
<file>/usr/lib</file> and <file>/lib</file>) or a directory that is
listed in <file>/etc/ld.so.conf</file><footnote>
- These are currently
- <list compact="compact">
- <item>/usr/local/lib</item>
- <item>/usr/lib/libc5-compat</item>
- <item>/lib/libc5-compat</item>
- </list>
+ These are currently <file>/usr/local/lib</file> plus
+ directories under <file>/lib</file> and <file>/usr/lib</file>
+ matching the multiarch triplet for the system architecture.
</footnote>
must use <prgn>ldconfig</prgn> to update the shared library
system.
to get access to kernel information.</footnote>
</p>
</item>
+ <item>
+ <p>
+ On GNU/Hurd systems, the following additional
+ directories are allowed in the root
+ filesystem: <file>/hurd</file>
+ and <file>/servers</file>.<footnote>
+ These directories are used to store translators and as
+ a set of standard names for mount points,
+ respectively.
+ </footnote>
+ </p>
+ </item>
</enumlist>
-
</p>
+
<p>
The version of this document referred here can be
found in the <tt>debian-policy</tt> package or on <url
</example>
must be supported and must set the value of <tt>c</tt> to
<tt>delta</tt>.
- </item>
+ </item>
+ <item>The XSI extension to <prgn>kill</prgn> allowing <tt>kill
+ -<var>signal</var></tt>, where <var>signal</var> is either
+ the name of a signal or one of the numeric signals listed in
+ the XSI extension (0, 1, 2, 3, 6, 9, 14, and 15), must be
+ supported if <prgn>kill</prgn> is implemented as a shell
+ built-in.
+ </item>
+ <item>The XSI extension to <prgn>trap</prgn> allowing numeric
+ signals must be supported. In addition to the signal
+ numbers listed in the extension, which are the same as for
+ <prgn>kill</prgn> above, 13 (SIGPIPE) must be allowed.
+ </item>
</list>
If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell
</p>
<p>
- Log files must be rotated occasionally so that they don't
- grow indefinitely; the best way to do this is to drop a log
- rotation configuration file into the directory
- <file>/etc/logrotate.d</file> and use the facilities provided by
- logrotate.<footnote>
+ Log files must be rotated occasionally so that they don't grow
+ indefinitely. The best way to do this is to install a log
+ rotation configuration file in the
+ directory <file>/etc/logrotate.d</file>, normally
+ named <file>/etc/logrotate.d/<var>package</var></file>, and use
+ the facilities provided by <prgn>logrotate</prgn>.
+ <footnote>
<p>
The traditional approach to log files has been to set up
<em>ad hoc</em> log rotation schemes using simple shell
section="8">):
<example compact="compact">
/var/log/foo/*.log {
-rotate 12
-weekly
-compress
-postrotate
-/etc/init.d/foo force-reload
-endscript
+ rotate 12
+ weekly
+ compress
+ missingok
+ postrotate
+ start-stop-daemon -K -p /var/run/foo.pid -s HUP -x /usr/sbin/foo -q
+ endscript
}
</example>
This rotates all files under <file>/var/log/foo</file>, saves 12
- compressed generations, and forces the daemon to reload its
- configuration information after the log rotation.
+ compressed generations, and tells the daemon to reopen its log
+ files after the log rotation. It skips this log rotation
+ (via <tt>missingok</tt>) if no such log file is present, which
+ avoids errors if the package is removed but not purged.
</p>
<p>
</footnote>
</p>
+ <p>
+ Control information files should be owned by <tt>root:root</tt>
+ and either mode 644 (for most files) or mode 755 (for
+ executables such as <qref id="maintscripts">maintainer
+ scripts</qref>).
+ </p>
<p>
Setuid and setgid executables should be mode 4755 or 2755
<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