X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=aa42b5d078c84b822aa89a1b04eeb7b931713432;hb=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8;hp=1fead8a47b7347e64a4b653f61b7cf33533f062f;hpb=776b3c76f338fbf07bde61ac1bcfd7efbbfe9069;p=debian%2Fdebian-policy.git
diff --git a/policy.sgml b/policy.sgml
index 1fead8a..aa42b5d 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -218,12 +218,13 @@
The actual editing is done by a group of maintainers that have
no editorial powers. These are the current maintainers:
-
@@ -257,7 +258,6 @@
+ Finally, a
+ The main archive area comprises the Debian
+ distribution. Only the packages in this area are considered
+ part of the distribution. None of the packages in
+ the main archive area require software outside of
+ that area to function. Anyone may use, share, modify and
+ redistribute the packages in this archive area
+ freely
Every package in main must comply with the DFSG
(Debian Free Software Guidelines).
@@ -473,11 +495,11 @@
In addition, the packages in main
+ The contrib archive area contains supplemental
+ packages intended to work with the Debian distribution, but
+ which require software outside of the distribution to either
+ build or function.
+
Every package in contrib must comply with the DFSG.
Examples of packages which would be included in
contrib are:
@@ -535,6 +563,15 @@
+ The non-free archive area contains supplemental
+ packages intended to work with the Debian distribution that do
+ not comply with the DFSG or have other problems that make
+ their distribution problematic. They may not comply with all
+ of the policy requirements in this manual due to restrictions
+ on modifications or other limitations.
+
Packages must be placed in non-free if they are
not compliant with the DFSG or are encumbered by patents
@@ -679,12 +716,13 @@
list of sections. At present, they are:
admin, cli-mono, comm, database,
devel, debug, doc, editors,
- electronics, embedded, fonts,
- games, gnome, graphics, gnu-r,
- gnustep, hamradio, haskell,
- httpd, interpreters, java, kde,
- kernel, libs, libdevel, lisp,
- localization, mail, math, misc,
+ education, electronics, embedded,
+ fonts, games, gnome, graphics,
+ gnu-r, gnustep, hamradio, haskell,
+ httpd, interpreters, introspection,
+ java, kde, kernel, libs,
+ libdevel, lisp, localization,
+ mail, math, metapackages, misc,
net, news, ocaml, oldlibs,
otherosfs, perl, php, python,
ruby, science, shells, sound,
@@ -1060,7 +1098,7 @@
@@ -1913,7 +1951,7 @@
- A package may also provide both of the targets
+ A package may also provide one or both of the targets
build-arch and build-indep.
The build-arch target, if provided, should
perform all the configuration and compilation required for
@@ -1926,9 +1964,13 @@
architecture-independent binary packages (those packages
for which the body of the Architecture field
in debian/control is all).
- The build target should depend on those of the
- targets build-arch and build-indep that
- are provided in the rules file.
+ If build-arch or build-indep targets are
+ provided in the rules file, the build target
+ should either depend on those targets or take the same
+ actions as invoking those targets would perform.
+ Each paragraph consists of a series of data fields. Each field
+ consists of the field name followed by a colon and then the
+ data/value associated with that field. The field name is
+ composed of US-ASCII characters excluding control characters,
+ space, and colon (i.e., characters in the ranges 33-57 and
+ 59-126, inclusive). Field names must not begin with the comment
+ character, #.
- Each paragraph consists of a series of data fields; each
- field consists of the field name, followed by a colon and
- then the data/value associated with that field. It ends at
- the end of the (logical) line. Horizontal whitespace
- (spaces and tabs) may occur immediately before or after the
- value and is ignored there; it is conventional to put a
- single space after the colon. For example, a field might
- be:
+ The field ends at the end of the line or at the end of the last
+ continuation line (see below). Horizontal whitespace (spaces
+ and tabs) may occur immediately before or after the value and is
+ ignored there; it is conventional to put a single space after
+ the colon. For example, a field might be:
- Many fields' values may span several lines; in this case
- each continuation line must start with a space or a tab.
- Any trailing spaces or tabs at the end of individual
- lines of a field value are ignored.
+ There are three types of fields:
+
- In fields where it is specified that lines may not wrap,
- only a single line of data is allowed and whitespace is not
- significant in a field body. Whitespace must not appear
+ Whitespace must not appear
inside names (of packages, architectures, files or anything
else) or version numbers, or between the characters of
multi-character version relationships.
+ The presence and purpose of a field, and the syntax of its
+ value may differ between types of control files.
+
Field names are not case-sensitive, but it is usual to
capitalize the field names using mixed case as shown below.
@@ -2502,9 +2584,17 @@ Package: libc6
- Blank lines, or lines consisting only of spaces and tabs,
- are not allowed within field values or between fields - that
- would mean a new paragraph.
+ Paragraph separators (empty lines) and lines consisting only of
+ spaces and tabs are not allowed within field values or between
+ fields. Empty lines in field values are usually escaped by
+ representing them by a space followed by a dot.
+
+ Lines starting with # without any preceding whitespace are comments
+ lines that are only permitted in source package control files
+ (
@@ -2535,7 +2625,7 @@ Package: libc6
- In addition to the control file syntax described
This file consists of a single paragraph, possibly surrounded by
a PGP signature. The fields of that paragraph are listed below.
- Their syntax is described above, in .
+ Their syntax is described above, in .
- The source package control file is generated by
+ The Debian source control file is generated by
- Any parser that interprets the Uploaders field in
-
- In the source package control file
+ The list may include (or consist solely of) the special
value all. In other words, in
- Specifying any indicates that the source package + Specifying only any indicates that the source package isn't dependent on any particular architecture and should compile fine on any one. The produced binary package(s) - will either be specific to whatever the current build - architecture is or will be architecture-independent. + will be specific to whatever the current build architecture is.
Specifying only all indicates that the source package - will only build architecture-independent packages. If this is - the case, all must be used rather than any; - any implies that the source package will build at - least one architecture-dependent package. + will only build architecture-independent packages. +
+ ++ Specifying any all indicates that the source package + isn't dependent on any particular architecture. The set of + produced binary packages will include at least one + architecture-dependant package and one architecture-independent + package.
@@ -2976,7 +3062,7 @@ Package: libc6
This is a boolean field which may occur only in the control file of a binary package or in a per-package fields - paragraph of a main source control data file. + paragraph of a source package control file.
@@ -3212,7 +3298,8 @@ Package: libc6 In a source or binary control file, the Description field contains a description of the binary package, consisting of two parts, the synopsis or the short description, and the - long description. The field's format is as follows: + long description. It is a multiline field with the following + format:
@@ -3232,6 +3319,7 @@ Package: libc6
Those starting with a single space are part of a paragraph.
Successive lines of this form will be word-wrapped when
displayed. The leading space will usually be stripped off.
+ The line must contain at least one non-whitespace character.
- This field contains the human-readable changes data, describing
+ This multiline field contains the human-readable changes data, describing
the differences between the last version and the current one.
- This field is a list of binary packages. Its syntax and
+ This folded field is a list of binary packages. Its syntax and
meaning varies depending on the control file in which it
appears.
When it appears in a
- These fields contain a list of files with a checksum and size
+ These multiline fields contain a list of files with a checksum and size
for each one. Both Checksums-Sha1
and Checksums-Sha256 have the same syntax and differ
only in the checksum algorithm used: SHA-1
@@ -3638,11 +3727,13 @@ Checksums-Sha256:
- The most recent version of a package uploaded to unstable or
- experimental must include the field DM-Upload-Allowed:
- yes in the source section of its source control file for
- the Debian archive to accept uploads signed with a key in the
- Debian Maintainer keyring. See the General
+ Indicates that Debian Maintainers may upload this package to
+ the Debian archive. The only valid value is yes. If
+ the field DM-Upload-Allowed: yes is present in the
+ source section of the source control file of the most recent
+ version of a package in unstable or experimental, the Debian
+ archive will accept uploads of this package signed with a key
+ in the Debian Maintainer keyring. See the General
Resolution
@@ -3674,7 +3765,7 @@ Checksums-Sha256:
field name after the hyphen will be used in the output
file. Where the letter B is used the field
will appear in binary package control files, where the
- letter S is used in source package control
+ letter S is used in Debian source control
files and where C is used in upload control
(.changes) files.
The relations allowed are <<, <=,
- =, >= and >> for
- strictly earlier, earlier or equal, exactly equal, later or
- equal and strictly later, respectively. The deprecated
- forms < and > were used to mean
- earlier/later or equal, rather than strictly earlier/later,
- so they should not appear in new packages (though
-
- For binary relationship fields, the architecture restriction
+ For binary relationship fields and the Built-Using
+ field, the architecture restriction
syntax is only supported in the source package control
file
Relationships may also be restricted to a certain set of - architectures using architecture wildcards. The syntax for + architectures using architecture wildcards in the format + described in . The syntax for declaring such restrictions is the same as declaring restrictions using a certain set of architectures without architecture wildcards. For example: @@ -4865,6 +4959,13 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] installation would hamper the ability of the system to continue with any upgrade that might be in progress.
+ ++ You should not specify a Pre-Depends entry for a + package before this has been discussed on the + debian-devel mailing list and a consensus about + doing that has been reached. See . +
@@ -5303,6 +5404,53 @@ Replaces: mail-transport-agent+ Some binary packages incorporate parts of other packages when built + but do not have to depend on those packages. Examples include + linking with static libraries or incorporating source code from + another package during the build. In this case, the source packages + of those other packages are a required part of the complete source + (the binary package is not reproducible without them). +
+ +
+ A Built-Using field must list the corresponding source
+ package for any such binary package incorporated during the build
+
+ A package using the source code from the gcc-4.6-source
+ binary package built from the gcc-4.6 source package would
+ have this field in its control file:
+
+ A package including binaries from grub2 and loadlin would
+ have this field in its control file:
+
- The location of all installed files and directories must
- comply with the Filesystem Hierarchy Standard (FHS),
- version 2.3, with the exceptions noted below, and except
- where doing so would violate other terms of Debian
- Policy. The following exceptions to the FHS apply:
+ The location of all files and directories must comply with the
+ Filesystem Hierarchy Standard (FHS), version 2.3, with the
+ exceptions noted below, and except where doing so would
+ violate other terms of Debian Policy. The following
+ exceptions to the FHS apply:
+ The additional directory
The following directories in the root filesystem are
@@ -6255,12 +6422,11 @@ install -m644 debian/shlibs.package debian/package/DEBIAN/
For example, the emacsen-common package could
contain something like
+ The directory
+ Packages must not include files or directories
+ under
-
Packages must not modify the configuration file
- If a package wants to install a job that has to be executed
- via cron, it should place a file with the name of the
- package in one or more of the following directories:
+ If a package wants to install a job that has to be executed via
+ cron, it should place a file named as specified
+ in into one or more of the following
+ directories:
All files installed in any of these directories must be @@ -7091,15 +7282,18 @@ Reloading description configuration...done.
If a certain job has to be executed at some other frequency or
- at a specific time, the package should install a file
-
Unlike
+ The file name of a cron job file should normally match the + name of the package from which it comes. +
+ ++ If a package supplies multiple cron job files files in the + same directory, the file names should all start with the name + of the package (possibly modified as described below) followed + by a hyphen (-) and a suitable suffix. +
+ ++ A cron job file name must not include any period or plus + characters (. or +) characters as this will + cause cron to ignore the file. Underscores (_) + should be used instead of . and + + characters. +
+
- The MIME support policy can be found in the mime-policy
- files in the debian-policy package.
- It is also available from the Debian web mirrors at
-
+ Packages containing such programs must register them
+ with
Please refer to the documentation that comes with the @@ -7796,10 +8027,13 @@ fname () {
You may wish to restrict your script to SUSv3 features plus the
above set when possible so that it may use
@@ -7838,11 +8072,23 @@ fname () {
- In general, symbolic links within a top-level directory
- should be relative, and symbolic links pointing from one
- top-level directory into another should be absolute. (A
- top-level directory is a sub-directory of the root
- directory
@@ -8095,22 +8341,6 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
- Packages which specify the same file as a
- conffile must be tagged as conflicting
- 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,
- The maintainer scripts must not alter a conffile
- of any package, including the one the scripts
- belong to.
-
If two or more packages use the same configuration file
and it is reasonable for both to be installed at the same
@@ -8160,6 +8390,34 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
and which manages the shared configuration files. (The
sgml-base package is a good example.)
+ 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 conffile 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,
+ When two packages both declare the same conffile, 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 conffile from the
+ old package. If the file was modified by the user, it will be
+ treated the same as any other locally
+ modified conffile during an upgrade.
+
+ The maintainer scripts must not alter a conffile
+ of any package, including the one the scripts
+ belong to.
+
- Programs that require the non-DFSG-compliant OSF/Motif or
- OpenMotif libraries
- Both Motif-linked versions are dependent - upon non-DFSG-compliant software and thus cannot be - uploaded to the main distribution; if the - software is itself DFSG-compliant it may be uploaded to - the contrib distribution. While known existing - versions of Motif permit unlimited redistribution of - binaries linked against the library (whether statically or - dynamically), it is the package maintainer's - responsibility to determine whether this is permitted by - the license of the copy of Motif in their possession. -
-In addition, the copyright file must say where the upstream - sources (if any) were obtained. It should name the original - authors of the package and the Debian maintainer(s) who were - involved with its creation. + sources (if any) were obtained, and should name the original + authors.
@@ -9721,8 +9943,8 @@ END-INFO-DIR-ENTRY
+ All copyright files must be encoded in UTF-8. +
+ +
+ A specification for a standard, machine-readable format
+ for
+ Use of this format is optional. +
+
- The Debian version of the FSF's GNU hello program is provided
- as an example for people wishing to create Debian
- packages. The Debian