X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=0bf1001f2486ae6ff362216a9efc69f0c09581fb;hb=c74ac744418a3a09b897fba405045aa079a086d2;hp=7d54e2920623f12542491f21d95e408885d6bed3;hpb=4e4e5d8bb9e85c94c19208a79ae61b7173bba55a;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 7d54e29..0bf1001 100644 --- a/policy.sgml +++ b/policy.sgml @@ -24,6 +24,13 @@ Copyright © 1996,1997,1998 Ian Jackson and Christian Schwarz. +
+ These are the copyright dates of the original Policy manual. + Since then, this manual has been updated by many others. No + comprehensive collection of copyright notices for subsequent + work exists. +
+
This manual is free software; you may redistribute it and/or
modify it under the terms of the GNU General Public License
@@ -318,8 +325,12 @@
system, but not every package we want to make accessible is
free in our sense (see the Debian Free Software
Guidelines, below), or may be imported/exported without
- restrictions. Thus, the archive is split into the distribution
- areas or categories based on their licenses and other restrictions.
+ restrictions. Thus, the archive is split into areas
@@ -336,12 +347,12 @@
- The main category forms the - Debian GNU/Linux distribution. + The main archive area forms the Debian GNU/Linux + distribution.
- Packages in the other distribution areas (contrib,
+ Packages in the other archive areas (contrib,
non-free) are not considered to be part of the Debian
distribution, although we support their use and provide
infrastructure for them (such as our bug-tracking system and
@@ -448,10 +459,10 @@
Every package in main must comply with the DFSG
@@ -482,7 +493,7 @@
Every package in contrib must comply with the DFSG.
@@ -522,7 +533,7 @@
Packages must be placed in non-free if they are
@@ -638,27 +649,27 @@
- The packages in the categories main,
- contrib and non-free are grouped further
- into sections to simplify handling.
+ The packages in the archive areas main,
+ contrib and non-free are grouped further into
+ sections to simplify handling.
- The category and section for each package should be
- specified in the package's Section control record
- (see ). However, the maintainer of the
- Debian archive may override this selection to ensure the
- consistency of the Debian distribution. The
- Section field should be of the form:
+ The archive area and section for each package should be
+ specified in the package's Section control record (see
+ ). However, the maintainer of the Debian
+ archive may override this selection to ensure the consistency of
+ the Debian distribution. The Section field should be
+ of the form:
The Debian archive maintainers provide the authoritative
list of sections. At present, they are:
- admin, comm,
- devel, doc,
- editors, electronics, embedded,
- games, gnome, graphics,
- hamradio, interpreters, kde,
- libs, libdevel, mail,
- math, misc, net, news,
- oldlibs,
- otherosfs, perl, python,
- science, shells,
- sound, tex, text,
- utils, web, x11.
+ 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,
+ net, news, ocaml, oldlibs,
+ otherosfs, perl, php, python,
+ ruby, science, shells, sound,
+ tex, text, utils, vcs,
+ video, web, x11, xfce,
+ zope.
- Essential is defined as the minimal set of functionality - that must be available and usable on the system even - when packages are in an unconfigured (but unpacked) - state. This is needed to avoid unresolvable dependency - loops on upgrade. If packages add unnecessary - dependencies on packages in this set, the chances that - there will be an unresolvable - dependency loop caused by forcing these Essential - packages to be configured first before they need to be - is greatly increased. It also increases the chances - that frontends will be unable to - calculate an upgrade path, even if one - exists. + Essential is needed in part to avoid unresolvable dependency + loops on upgrade. If packages add unnecessary dependencies + on packages in this set, the chances that there + will be an unresolvable dependency loop + caused by forcing these Essential packages to be configured + first before they need to be is greatly increased. It also + increases the chances that frontends will be unable to + calculate an upgrade path, even if one + exists.
- Also, it's pretty unlikely that functionality from - Essential shall ever be removed (which is one reason why - care must be taken before adding to the Essential - packages set), but packages have been removed - from the Essential set when the functionality moved to a - different package. So depending on these packages - just in case they stop being essential does way - more harm than good. + Also, functionality is rarely ever removed from the + Essential set, but packages have been removed from + the Essential set when the functionality moved to a + different package. So depending on these packages just + in case they stop being essential does way more harm + than good.
- Some packages are tagged essential for a system - using the Essential control file field. - The format of the Essential control field is - described in . + Essential is defined as the minimal set of functionality that + must be available and usable on the system at all times, even + when packages are in an unconfigured (but unpacked) state. + Packages are tagged essential for a system using the + Essential control file field. The format of the + Essential control field is described in .
@@ -1147,6 +1158,19 @@ appropriate.
++ Maintainers should take great care in adding any programs, + interfaces, or functionality to essential packages. + Packages may assume that functionality provided by + essential packages is always available without + declaring explicit dependencies, which means that removing + functionality from the Essential set is very difficult and is + almost never done. Any capability added to an + essential package therefore creates an obligation to + support that capability as part of the Essential set in + perpetuity. +
+
You must not tag any packages essential before
this has been discussed on the debian-devel
@@ -1203,21 +1227,20 @@
Package maintainer scripts may prompt the user if
- necessary. Prompting should be done by communicating
+ necessary. Prompting must be done by communicating
through a program, such as
+ Packages which are essential, or which are dependencies of + essential packages, may fall back on another prompting method + if no such interface is available when they are executed.
- The Debian Configuration management specification is included
+ The Debian Configuration Management Specification is included
in the
- Packages which use the Debian Configuration management
- specification may contain an additional
+ Packages which use the Debian Configuration Management
+ Specification may contain an additional
- Packages which use the Debian Configuration management
- specification must allow for translation of their messages
- by using a gettext-based system such as the one provided by
- the
@@ -1620,7 +1643,7 @@
its copyright and distribution license in the file
Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. + Field values are case-sensitive unless the description of the + field says otherwise.
@@ -2435,6 +2468,15 @@ Package: libc6 See for details.
+
+ In addition to the control file syntax described
+ Package names (both source and binary, + see ) must consist only of lower case + letters (a-z), digits (0-9), plus + (+) and minus (-) signs, and periods + (.). They must be at least two characters long and + must start with an alphanumeric character. +
- Package names must consist only of lower case letters - (a-z), digits (0-9), plus (+) - and minus (-) signs, and periods (.). - They must be at least two characters long and must start - with an alphanumeric character. + Binary package names must follow the same syntax and + restrictions as source package names. See + for the details.
In the main
+ In the source package control file
Specifying 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 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.
Specifying a list of architectures indicates that the source
will build an architecture-dependent package, and will only
- work correctly on the listed architectures.
@@ -2720,7 +2791,11 @@ Package: libc6
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
source for the package is also being uploaded, the special
- entry source is also present.
+ entry source is also present. all will be
+ present if any architecture-independent packages are being
+ uploaded. any may never occur in the
+ Architecture field in the
@@ -3028,18 +3103,16 @@ Package: libc6
- In a
- The part of the field before the first newline is empty;
- thereafter each line has the name of a binary package and
- the summary description line from that binary package.
- Each line is indented by one space.
+ In a
- You should list all distributions that the - package should be installed into. -
- -- More information is available in the Debian Developer's - Reference, section "The Debian archive". + Others are used for updating stable releases or for + security uploads. More information is available in the + Debian Developer's Reference, section "The Debian + archive".
- There should be nothing in this field before the first - newline; all the subsequent lines must be indented by at - least one space; blank lines must be represented by a line - consisting only of a space and a full stop. + The first line of the field value (the part on the same line + as Changes:) is always empty. The content of the + field is expressed as continuation lines, with each line + indented by at least one space. Blank lines must be + represented by a line consisting only of a space and a full + stop (.).
@@ -3224,29 +3262,27 @@ Package: libc6
- This field is a list of binary packages. + This 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 the
- When it appears in a
- The syntax is a list of binary packages separated by
- commas
- This field appears in the control files of binary
- packages, and in the
- The disk space is represented in kilobytes as a simple - decimal number. + The disk space is given as the integer value of the estimated + installed size in bytes, divided by 1024 and rounded up.
@@ -3272,20 +3310,30 @@ Package: libc6This field contains a list of files with information about each one. The exact information and syntax varies with - the context. In all cases the part of the field - contents on the same line as the field name is empty. The - remainder of the field is one line per file, each line - being indented by one space and containing a number of - sub-fields separated by spaces. + the context. +
+ ++ In all cases, Files is a multiline field. The first line of + the field value (the part on the same line as Files:) + is always empty. The content of the field is expressed as + continuation lines, one line per file. Each line must be + indented by one space and contain a number of sub-fields, + separated by spaces, as described below.
In the
In the
@@ -3425,8 +3479,7 @@ Package: libc6 scripts this means that you almost always need to use set -e (this is usually true when writing shell scripts, in fact). It is also important, of course, that - they don't exit with a non-zero status if everything went - well. + they exit with a zero status if everything went well.
@@ -4178,6 +4231,22 @@ Build-Depends-Indep: texinfo Build-Depends: kernel-headers-2.2.10 [!hurd-i386], hurd-dev [hurd-i386], gnumach-dev [hurd-i386] + requires kernel-headers-2.2.10 on all architectures + other than hurd-i386 and requires hurd-dev and + gnumach-dev only on hurd-i386. +
+ +
+ If the architecture-restricted dependency is part of a set of
+ alternatives using |, that alternative is ignored
+ completely on architectures that do not match the restriction.
+ For example:
+
@@ -4207,6 +4276,9 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386], This is done using the Depends, Pre-Depends, Recommends, Suggests, Enhances, Breaks and Conflicts control file fields. + Breaks is described in , and + Conflicts is described in . The + rest are described below.
@@ -4394,12 +4466,6 @@ Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
- Using Breaks may cause problems for upgrades from older
- versions of Debian and should not be used until the stable
- release of Debian supports Breaks.
-
When one binary package declares that it breaks another,
The location of all installed files and directories must
- comply with the File system Hierarchy Standard (FHS),
+ 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:
- Legacy XFree86 servers are permitted to retain the
- configuration file location
-
The optional rules related to user specific
@@ -5524,6 +5582,40 @@ libbar 1 bar1 (>= 1.0-1)
for 64 bit binaries is removed.
+ The requirement for object files, internal binaries, and
+ libraries, including
+ Applications may also use a single subdirectory under
+
+ The execution time linker/loader, ld*, must still be made
+ available in the existing location under /lib or /lib64
+ since this is part of the ELF ABI for the architecture.
+
The requirement that
@@ -5664,12 +5756,6 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
by any particular mail agents. The use of the old
location
- Also, if the script name ends in .sh, the script
- will be sourced in runlevel S rather than being
- run in a forked subprocess, but will be explicitly run by
-
+
- Note that the same symbol (") is used for the left - and right quotation marks. A grave accent (`) is - not a quote character; neither is an apostrophe - ('). + Note that the same symbol (") is used + for the left and right quotation marks. A grave accent + (`) is not a quote character; neither is an + apostrophe (').
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- compelling reason can not be installed in
-
An ever increasing number of packages are using
@@ -8062,12 +8150,27 @@ http://localhost/doc/package/filename
- Mailboxes are generally mode 660
- user:mail unless the system
- administrator has chosen otherwise. A MUA may remove a
- mailbox (unless it has nonstandard permissions) in which
- case the MTA or another MUA must recreate it if needed.
- Mailboxes must be writable by group mail.
+ Mailboxes are generally either mode 600 and owned by
+ user or mode 660 and owned by
+ user:mail
@@ -8366,11 +8469,6 @@ name ["syshostname"]:
@@ -8526,54 +8624,35 @@ name ["syshostname"]:
- Packages using the X Window System should not be
- configured to install files under the
-
- Programs that use GNU
- The installation of files into subdirectories
- of
- Packages should install any relevant files into the
- directories
- These libraries used to be all symbolic
- links. However, with X11R7,
- /usr/include/X11 and /usr/lib/X11
- are now real directories, and packages
- should ship their files here instead
- of in /usr/X11R6/{include,lib}/X11.
- x11-common (>= 1:7.0.0) is the package
- responsible for converting these symlinks into
- directories.
-
- Due to limitations in current implementations, all characters
- in the manual page source should be representable in the usual
- legacy encoding for that language, even if the file is
- actually encoded in UTF-8. Safe alternative ways to write many
- characters outside that range may be found in
-
- Your package should call
- It is a good idea to specify a section for the location of
- your program; this is done with the --section
- switch. To determine which section to use, you should look
- at
- You should remove the entries in the
- If
+ Info documents should contain section and directory entry
+ information in the document for the use
+ of
- Packages in the contrib or non-free categories - should state in the copyright file that the package is not part - of the Debian GNU/Linux distribution and briefly explain why. + Packages in the contrib or non-free archive + areas should state in the copyright file that the package is not + part of the Debian GNU/Linux distribution and briefly explain + why.
@@ -8988,8 +9084,8 @@ install-info --quiet --remove /usr/share/info/foobar.info
Packages distributed under the UCB BSD license, the Apache
license (version 2.0), the Artistic license, the GNU GPL
- (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and
- the GNU FDL (version 1.2) should refer to the corresponding
+ (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the
+ GNU FDL (versions 1.2 or 1.3) should refer to the corresponding
files under
In particular,
@@ -9000,8 +9096,9 @@ install-info --quiet --remove /usr/share/info/foobar.info
The postrm has to do the reverse: