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
+ 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
(<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
</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