<p>
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.<footnote>
- If the developer uploading the package is not one of the usual
- maintainers of the package (as listed in
+ should be the details of the person who prepared this release of
+ the package. They are <em>not</em> necessarily those of the
+ uploader or usual package maintainer.<footnote>
+ In the case of a sponsored upload, the uploader signs the
+ files, but the changelog maintainer name and address are those
+ of the person who prepared this release. If the preparer of
+ the release 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
This is an optional, recommended configuration file for the
<tt>uscan</tt> utility which defines how to automatically scan
ftp or http sites for newly available updates of the
- package. This is used
- by <url id="http://dehs.alioth.debian.org/"> and other Debian QA
+ package. This is used Debian QA
tools to help with quality control and maintenance of the
distribution as a whole.
</p>
<p>
The special value <tt>byhand</tt> for the section in a
<tt>.changes</tt> file indicates that the file in question
- is not an ordinary package file and must by installed by
+ is not an ordinary package file and must be installed by
hand by the distribution maintainers. If the section is
<tt>byhand</tt> the priority should be <tt>-</tt>.
</p>
exceptions to the FHS apply:
<enumlist>
+ <item>
+ <p>
+ The FHS requirement that architecture-independent
+ application-specific static files be located in
+ <file>/usr/share</file> is relaxed to a suggestion.
+
+ In particular, a subdirectory of <file>/usr/lib</file> may
+ be used by a package (or a collection of packages) to hold a
+ mixture of architecture-independent and
+ architecture-dependent files. However, when a directory is
+ entirely composed of architecture-independent files, it
+ should be located in <file>/usr/share</file>.
+ </p>
+ </item>
<item>
<p>
The optional rules related to user specific
<footnote>
This is necessary in order to reserve the directories for
use in cross-installation of library packages from other
- architectures, as part of the planned deployment of
- <tt>multiarch</tt>.
+ architectures, as part of <tt>multiarch</tt>.
+ </footnote>
+ </p>
+ <p>
+ The requirement for C and C++ headers files to be
+ accessible through the search path
+ <file>/usr/include/</file> is amended, permitting files to
+ be accessible through the search path
+ <file>/usr/include/<var>triplet</var></file> where
+ <tt><var>triplet</var></tt> is as above. <footnote>
+ This is necessary for architecture-dependant headers
+ file to coexist in a <tt>multiarch</tt> setup.
</footnote>
</p>
<p>
kernel information.</footnote>
</p>
</item>
+ <item>
+ <p>
+ The requirement for <file>/usr/local/lib<qual></file>
+ to exist if <file>/lib<qual></file> or
+ <file>/usr/lib<qual></file> exists (where
+ <file>lib<qual></file> is a variant of
+ <file>lib</file> such as <file>lib32</file> or
+ <file>lib64</file>) is removed.
+ </p>
+ </item>
<item>
<p>
On GNU/Hurd systems, the following additional
renamed. If a consensus cannot be reached, <em>both</em>
programs must be renamed.
</p>
-
+ <p>
+ Binary executables must not be statically linked with the GNU C
+ library, since this prevents the binary from benefiting from
+ fixes and improvements to the C library without being rebuilt
+ and complicates security updates. This requirement may be
+ relaxed for binary executables whose intended purpose is to
+ diagnose and fix the system in situations where the GNU C
+ library may not be usable (such as system recovery shells or
+ utilities like ldconfig) or for binary executables where the
+ security benefits of static linking outweigh the drawbacks.
+ </p>
<p>
By default, when a package is being built, any binaries
created should include debugging information, as well as
Cgi-bin executable files are installed in the
directory
<example compact="compact">
-/usr/lib/cgi-bin/<var>cgi-bin-name</var>
+/usr/lib/cgi-bin
+ </example>
+ or a subdirectory of that directory, and the script
+ <example compact="compact">
+/usr/lib/cgi-bin/.../<var>cgi-bin-name</var>
</example>
- or a subdirectory of that directory, and should be
- referred to as
+ should be referred to as
<example compact="compact">
-http://localhost/cgi-bin/<var>cgi-bin-name</var>
+http://localhost/cgi-bin/.../<var>cgi-bin-name</var>
</example>
- (possibly with a subdirectory name
- before <var>cgi-bin-name</var>).
</item>
<item>
projects / debian / debian-policy.git / blobdiff