X-Git-Url: https://git.donarmstrong.com/?p=debian%2Fdebian-policy.git;a=blobdiff_plain;f=policy.sgml;h=404dc7373f80cdc20bf793e064d7163e3885518f;hp=fa0a390cf08308c5ed2c57886845ec64e9a66d18;hb=HEAD;hpb=a455d2387d8ef592eca042366eed6247ab0d587d
diff --git a/policy.sgml b/policy.sgml
index fa0a390..404dc73 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -229,9 +229,8 @@
- Russ Allbery
- Bill Allombert
- - Andrew McMillan
- - Manoj Srivastava
- - Colin Watson
+ - Andreas Barth
+ - Jonathan Nieder
@@ -1746,11 +1745,14 @@ zope.
The maintainer name and email address used in the changelog
- should be the details of the person uploading this
- version. They are not necessarily those of the
- usual package maintainer.
- 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 not necessarily those of the
+ uploader or usual package maintainer.
+ 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 Maintainer
or Uploaders control
fields of the package), the first line of the changelog is
@@ -1929,6 +1931,10 @@ zope.
any target that these targets depend on must also be
non-interactive.
+
+ For packages in the main archive, no required targets
+ may attempt network access.
+
The targets are as follows:
@@ -2556,7 +2562,9 @@ Package: libc6
the field name is Package and the field value
libc6.
-
+ Empty field values are only permitted in source package control files
+ (debian/control). Such fields are ignored.
+
A paragraph must not contain more than one instance of a
particular field name.
@@ -2699,6 +2707,7 @@ Package: libc6
file. These tools are responsible for removing the line
breaks from such fields when using fields from
debian/control to generate other control files.
+ They are also responsible for discarding empty fields.
@@ -3673,7 +3682,7 @@ Files:
The special value byhand for the section in a
.changes 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
byhand the priority should be -.
@@ -6972,8 +6981,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
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
- multiarch.
+ architectures, as part of multiarch.
@@ -7053,6 +7061,11 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
kernel information.
+ -
+
+ The /var/www directory is additionally allowed.
+
+
-
The requirement for /usr/local/lib<qual>
@@ -7343,6 +7356,35 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
65535:
+ -
+
+ This value must not be used, because it was
+ the error return sentinel value when uid_t
+ was 16 bits.
+
+
+
+ 65536-4294967293:
+ -
+
+ Dynamically allocated user accounts. By
+ default adduser will not allocate UIDs
+ and GIDs in this range, to ease compatibility with
+ legacy systems where uid_t is still 16
+ bits.
+
+
+
+ 4294967294:
+ -
+
+ (uid_t)(-2) == (gid_t)(-2) must not be
+ used, because it is used as the anonymous, unauthenticated
+ user by some NFS implementations.
+
+
+
+ 4294967295:
-
(uid_t)(-1) == (gid_t)(-1) must
@@ -8466,7 +8508,17 @@ fi
renamed. If a consensus cannot be reached, both
programs must be renamed.
-
+
+ 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.
+
By default, when a package is being built, any binaries
created should include debugging information, as well as
@@ -8875,6 +8927,7 @@ fname () {
would point to /srv/run rather than the intended
target.
+ Symbolic links must not traverse above the root directory.
@@ -9773,7 +9826,7 @@ http://localhost/cgi-bin/.../cgi-bin-name
doc-base package. If access to the
web document root is unavoidable then use
-/var/www
+/var/www/html
as the Document Root. This might be just a symbolic
link to the location where the system administrator
@@ -10609,45 +10662,77 @@ END-INFO-DIR-ENTRY
-
+
Additional documentation
- Any additional documentation that comes with the package may
- be installed at the discretion of the package maintainer.
- Plain text documentation should be installed in the directory
- /usr/share/doc/package, where
- package is the name of the package, and
- compressed with gzip -9 unless it is small.
-
+ Any additional documentation that comes with the package may be
+ installed at the discretion of the package maintainer. It is
+ often a good idea to include text information files
+ (READMEs, FAQs, and so forth) that come with the
+ source package in the binary package. However, you don't need
+ to install the instructions for building and installing the
+ package, of course!
+
- If a package comes with large amounts of documentation which
- many users of the package will not require you should create
- a separate binary package to contain it, so that it does not
- take up disk space on the machines of users who do not need
- or want it installed.
+ Plain text documentation should be compressed with gzip
+ -9 unless it is small.
+
- It is often a good idea to put text information files
- (READMEs, changelogs, and so forth) that come with
- the source package in /usr/share/doc/package
- in the binary package. However, you don't need to install
- the instructions for building and installing the package, of
- course!
+ If a package comes with large amounts of documentation that many
+ users of the package will not require, you should create a
+ separate binary package to contain it so that it does not take
+ up disk space on the machines of users who do not need or want
+ it installed. As a special case of this rule, shared library
+ documentation of any appreciable size should always be packaged
+ with the library development package ([)
+ or in a separate documentation package, since shared libraries
+ are frequently installed as dependencies of other packages by
+ users who have little interest in documentation of the library
+ itself. The documentation package for the
+ package package is conventionally
+ named package-doc
+ (or package-doc-language-code if there are
+ separate documentation packages for multiple languages).
+
+
+ ]
+ Additional documentation included in the package should be
+ installed under /usr/share/doc/package.
+ If the documentation is packaged separately,
+ as package-doc for example, it may be installed under
+ either that path or into the documentation directory for the
+ separate documentation package
+ (/usr/share/doc/package-doc in this
+ example). However, installing the documentation into the
+ documentation directory of the main package is preferred since
+ it is independent of the packaging method and will be easier for
+ users to find.
+
+
+
+ Any separate package providing documentation must still install
+ standard documentation files in its
+ own /usr/share/doc directory as specified in the
+ rest of this policy. See, for example, [
+ and ][.
+ ]
Packages must not require the existence of any files in
/usr/share/doc/ in order to function
- The system administrator should be able to
- delete files in /usr/share/doc/ without causing
- any programs to break.
- .
- Any files that are referenced by programs but are also
- useful as stand alone documentation should be installed under
- /usr/share/package/ with symbolic links from
- /usr/share/doc/package.
+ The system administrator should be able to delete files
+ in /usr/share/doc/ without causing any programs
+ to break.
+ . Any files that are used or read by programs but
+ are also useful as stand alone documentation should be installed
+ elsewhere, such as
+ under /usr/share/package/, and then
+ included via symbolic links
+ in /usr/share/doc/package.
@@ -10667,18 +10752,6 @@ END-INFO-DIR-ENTRY
-
-
- Former Debian releases placed all additional documentation
- in /usr/doc/package. This has been
- changed to /usr/share/doc/package,
- and packages must not put documentation in the directory
- /usr/doc/package.
- At this phase of the transition, we no longer require a
- symbolic link in /usr/doc/. At a later point,
- policy shall change to make the symbolic links a bug.
-
-
@@ -10689,16 +10762,16 @@ END-INFO-DIR-ENTRY
via HTML.
- If your package comes with extensive documentation in a
+ If the package comes with extensive documentation in a
markup format that can be converted to various other formats
you should if possible ship HTML versions in a binary
- package, in the directory
- /usr/share/doc/appropriate-package or
- its subdirectories.
- The rationale: The important thing here is that HTML
- docs should be available in some package, not
- necessarily in the main binary package.
+ package.
+ Rationale: The important thing here is that HTML
+ documentation should be available from some
+ binary package.
+ The documentation must be installed as specified in
+ [.
]