<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>
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>
(<prgn>ld</prgn>) when compiling packages, as it will only look for
<file>libgdbm.so</file> when compiling dynamically.
</p>
+
+ <p>
+ If the package provides Ada Library Information
+ (<file>*.ali</file>) files for use with GNAT, these files must be
+ installed read-only (mode 0444) so that GNAT will not attempt to
+ recompile them. This overrides the normal file mode requirements
+ given in <ref id="permissions-owners">.
+ </p>
</sect>
<sect id="sharedlibs-intradeps">
</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
<sect1>
<heading>Sharing configuration files</heading>
- <p>
- Packages which specify the same file as a
- <tt>conffile</tt> must be tagged as <em>conflicting</em>
- with each other. (This is an instance of the general rule
- about not sharing files. Note that neither alternatives
- nor diversions are likely to be appropriate in this case;
- in particular, <prgn>dpkg</prgn> does not handle diverted
- <tt>conffile</tt>s well.)
- </p>
-
- <p>
- The maintainer scripts must not alter a <tt>conffile</tt>
- of <em>any</em> package, including the one the scripts
- belong to.
- </p>
-
<p>
If two or more packages use the same configuration file
and it is reasonable for both to be installed at the same
and which manages the shared configuration files. (The
<tt>sgml-base</tt> package is a good example.)
</p>
+
+ <p>
+ If the configuration file cannot be shared as described above,
+ the packages must be marked as conflicting with each other.
+ Two packages that specify the same file as
+ a <tt>conffile</tt> must conflict. This is an instance of the
+ general rule about not sharing files. Neither alternatives
+ nor diversions are likely to be appropriate in this case; in
+ particular, <prgn>dpkg</prgn> does not handle diverted
+ <tt>conffile</tt>s well.
+ </p>
+
+ <p>
+ When two packages both declare the same <tt>conffile</tt>, they
+ may see left-over configuration files from each other even
+ though they conflict with each other. If a user removes
+ (without purging) one of the packages and installs the other,
+ the new package will take over the <tt>conffile</tt> from the
+ old package. If the file was modified by the user, it will be
+ treated the same as any other locally
+ modified <tt>conffile</tt> during an upgrade.
+ </p>
+
+ <p>
+ The maintainer scripts must not alter a <tt>conffile</tt>
+ of <em>any</em> package, including the one the scripts
+ belong to.
+ </p>
</sect1>
<sect1>
</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>
</p>
</sect>
- <sect>
+ <sect id="permissions-owners">
<heading>Permissions and owners</heading>
<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