<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
<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>
<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 <file>/var/www</file> directory is additionally allowed.
+ </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 is removed.
- </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>
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
<package>doc-base</package> package. If access to the
web document root is unavoidable then use
<example compact="compact">
-/var/www
+/var/www/html
</example>
as the Document Root. This might be just a symbolic
link to the location where the system administrator