X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=2f4c935114069618e46cfe099d534486ca64d611;hb=21df36b8215e66ff6a1f66de5418660dc032df99;hp=96a77b80b89da5ee0d04fa157198d9aafbaf33f4;hpb=70cbf8d088bf52307eb8a7221b890370a8b340e0;p=debian%2Fdebian-policy.git
diff --git a/policy.sgml b/policy.sgml
index 96a77b8..2f4c935 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2,6 +2,8 @@
%versiondata;
+
+
]>
+ For more information about the sections and their definitions,
+ see the
- Sometimes, a package requires another package to be installed - and configured before it can be installed. In this + Sometimes, a package requires another package to be unpacked + and configured before it can be unpacked. In this case, you must specify a Pre-Depends entry for the package.
@@ -1610,11 +1622,38 @@
- The date must be in RFC822 format
+
@@ -1753,7 +1792,7 @@
The build target should perform all the
configuration and compilation of the package.
If a package has an interactive pre-build
- configuration routine, the Debianized source package
+ configuration routine, the Debian source package
must either be built after this has taken place (so
that the binary package can be built without rerunning
the configuration) or the configuration routine
@@ -1819,21 +1858,28 @@
A package may also provide both of the targets
build-arch and build-indep.
The build-arch target, if provided, should
- perform all the configuration and compilation required
- for producing all architecture-dependant binary packages
- (those packages for which the body of the
- Architecture field in debian/control
- is not all).
- Similarly, the build-indep target, if
- provided, should perform all the configuration and
- compilation required for producing all
- architecture-independent binary packages
+ perform all the configuration and compilation required for
+ producing all architecture-dependant binary packages
(those packages for which the body of the
- Architecture field in debian/control
- is all).
+ Architecture field in debian/control is
+ not all). Similarly, the build-indep
+ target, if provided, should perform all the configuration
+ and compilation required for producing all
+ 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.
+ are provided in the rules file.
@@ -2362,6 +2408,11 @@ Package: libc6 libc6.
++ A paragraph must not contain more than one instance of a + particular field name. +
+Many fields' values may span several lines; in this case each continuation line must start with a space or a tab. @@ -2446,13 +2497,11 @@ Package: libc6 The syntax and semantics of the fields are described below.
- -
These fields are used by
The
@@ -2513,23 +2563,24 @@ Package: libc6
- This file contains a series of fields, identified and
- separated just like the fields in the control file of
- a binary package. The fields are listed below; their
- syntax is described above, in .
+ 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 .
- The .changes files are used by the Debian archive maintenance
- software to process updates to packages. They contain one
- paragraph which contains information from the
- debian/control file and other data about the
- source package gathered via debian/changelog
- and debian/rules.
+ The
+
@@ -2573,6 +2631,8 @@ Package: libc6
The package maintainer's name and email address. The name - should come first, then the email address inside angle - brackets <> (in RFC822 format). + must come first, then the email address inside angle + brackets <> (in RFC822 format).
@@ -2641,17 +2701,17 @@ Package: libc6
- List of the names and email addresses of co-maintainers of
- the package, if any. If the package has other maintainers
- beside the one named in the
-
+ List of the names and email addresses of co-maintainers of
+ the package, if any. If the package has other maintainers
+ beside the one named in the
+
Any parser that interprets the Uploaders field in
- The name and email address of the person who changed the
- said package. Usually the name of the maintainer.
- All the rules for the Maintainer field apply here, too.
+ The name and email address of the person who prepared this
+ version of the package, usually a maintainer. The syntax is
+ the same as for the
-
In the main
+ Specifying a specific list of architectures indicates that the + source will build an architecture-dependent package only on + architectures included in the list. Specifying a list of + architecture wildcards indicates that the source will build an + architecture-dependent package on only those architectures + that match any of the specified architecture wildcards. + Specifying a list of architectures or architecture wildcards + other than any is for the minority of cases where a + program is not portable or is not useful on some + architectures. Where possible, the program should be made + portable instead.
In the source package control file
@@ -2781,23 +2865,24 @@ Package: libc6
- Specifying a list of architectures indicates that the source - will build an architecture-dependent package, and will only - work correctly on the listed architectures. If the source - package also builds at least one architecture-independent - package, all will also be included in the list. + Specifying a list of architectures or architecture wildcards + indicates that the source will build an architecture-dependent + package, and will only work correctly on the listed or + matching architectures. If the source package also builds at + least one architecture-independent package, all will + also be included in the list.
In a
@@ -2953,9 +3038,10 @@ Package: libc6 It is optional; if it isn't present then the upstream_version may not contain a hyphen. This format represents the case where a piece of - software was written specifically to be turned into a - Debian package, and so there is only one "debianisation" - of it and therefore no revision indication is required. + software was written specifically to be a Debian + package, where the Debian package source must always + be identical to the pristine source and therefore no + revision indication is required.
@@ -3031,10 +3117,12 @@ Package: libc6
not intended to cope with version numbers containing
strings of letters which the package management system cannot
interpret (such as ALPHA or pre-), or with
- silly orderings (the author of this manual has heard of a
- package whose versions went 1.1, 1.2,
- 1.3, 1, 2.1, 2.2,
- 2 and so forth).
+ silly orderings.
- This field includes the date the package was built or last edited.
+ This field includes the date the package was built or last
+ edited. It must be in the same format as the date
+ in a
@@ -3180,12 +3270,30 @@ Package: libc6
- This field specifies a format revision for the file.
- The most current format described in the Policy Manual
- is version 1.5. The syntax of the
- format value is the same as that of a package version
- number except that no epoch or Debian revision is allowed
- - see .
+ In
+ In
+ These 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 + for Checksums-Sha1 and SHA-256 + for Checksums-Sha256. +
+ +
+ Checksums-Sha1 and Checksums-Sha256 are
+ multiline fields. The first line of the field value (the part
+ on the same line as Checksums-Sha1:
+ or Checksums-Sha256:) is always empty. The content
+ of the field is expressed as continuation lines, one line per
+ file. Each line consists of the checksum, a space, the file
+ size, a space, and the file name. For example (from
+ a
+ In the
Broadly speaking the
- The maintainer scripts are guaranteed to run with a - controlling terminal and can interact with the user. - Because these scripts may be executed with standard output - redirected into a pipe for logging purposes, Perl scripts - should set unbuffered output by setting $|=1 so - that the output is printed immediately rather than being - buffered. + Maintainer scripts are not guaranteed to run with a controlling + terminal and may not be able to interact with the user. They + must be able to fall back to noninteractive behavior if no + controlling terminal is available. Maintainer scripts that + prompt via a program conforming to the Debian Configuration + Management Specification (see ) may + assume that program will handle falling back to noninteractive + behavior. +
+ ++ For high-priority prompts without a reasonable default answer, + maintainer scripts may abort if there is no controlling + terminal. However, this situation should be avoided if at all + possible, since it prevents automated or unattended installs. + In most cases, users will consider this to be a bug in the + package.
+ All fields that specify build-time relationships may also be
+ restricted to a certain set of architectures using architecture
+ wildcards. The syntax for declaring such restrictions is the
+ same as declaring restrictions using a certain set of
+ architectures without architecture wildcards. For example:
+
Note that the binary package relationship fields such as Depends appear in one of the binary package @@ -4315,31 +4493,30 @@ Build-Depends: foo [!i386] | bar [!amd64]
- For this reason packages in an installation run are usually - all unpacked first and all configured later; this gives - later versions of packages with dependencies on later - versions of other packages the opportunity to have their - dependencies satisfied. + Since Depends only places requirements on the + configuration step, packages in an installation run are usually + all unpacked first and all configured later. This makes it + easier to satisfy all dependencies when multiple packages are + being upgraded.
-- In case of circular dependencies, since installation or - removal order honoring the dependency order can't be - established, dependency loops are broken at some point - (based on rules below), and some packages may not be able to - rely on their dependencies being present when being - installed or removed, depending on which side of the break - of the circular dependency loop they happen to be on. If one - of the packages in the loop has no postinst script, then the - cycle will be broken at that package, so as to ensure that - all postinst scripts run with the dependencies properly - configured if this is possible. Otherwise the breaking point - is arbitrary. -
-
- The Depends field thus allows package maintainers
- to impose an order in which packages should be configured.
+ If there is a circular dependency among packages being installed
+ or removed, installation or removal order honoring the
+ dependency order is impossible, requiring the dependency loop be
+ broken at some point and the dependency requirements violated
+ for at least one package. Packages involved in circular
+ dependencies may not be able to rely on their dependencies being
+ configured when being configured or removed depending on which
+ side of the break of the circular dependency loop they happen to
+ be on. If one of the packages in the loop has no
+
@@ -4351,7 +4528,8 @@ Build-Depends: foo [!i386] | bar [!amd64] This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly - configured. + configured (unless there is a circular dependency as + described above).
@@ -4365,10 +4543,17 @@ Build-Depends: foo [!i386] | bar [!amd64]
The Depends field should also be used if the
+ Pre-Depends are also required if the
+
@@ -4440,13 +4635,6 @@ Build-Depends: foo [!i386] | bar [!amd64] installation would hamper the ability of the system to continue with any upgrade that might be in progress.
- -
- Pre-Depends are also required if the
-
When one binary package declares that it breaks another,
Normally a Breaks entry will have an "earlier than" version clause; such a Breaks is introduced in the - version of an (implicit or explicit) dependency which - violates an assumption or reveals a bug in earlier versions - of the broken package. This use of Breaks will - inform higher-level package management tools that broken - package must be upgraded before the new one. + version of an (implicit or explicit) dependency which violates + an assumption or reveals a bug in earlier versions of the broken + package, or which takes over a file from earlier versions of the + package named in Breaks. This use of Breaks + will inform higher-level package management tools that the + broken package must be upgraded before the new one.
If the breaking package also overwrites some files from the - older package, it should use Replaces (not - Conflicts) to ensure this goes smoothly. + older package, it should use Replaces to ensure this + goes smoothly. See for a full discussion + of taking over files from other packages, including how to + use Breaks in those cases. +
+ ++ Many of the cases where Breaks should be used were + previously handled with Conflicts + because Breaks did not yet exist. + Many Conflicts fields should now be Breaks. + See for more information about the + differences.
When one binary package declares a conflict with another
using a Conflicts field,
- If one package is to be installed, the other must be removed
- first - if the package being installed is marked as
- replacing (see ) the one on the system,
- or the one on the system is marked as deselected, or both
- packages are marked Essential, then
-
@@ -4547,12 +4750,52 @@ Build-Depends: foo [!i386] | bar [!amd64]
- A Conflicts entry should almost never have an
- "earlier than" version clause. This would prevent
-
+
+ Conflicts should be used
+
+
+ Be aware that adding Conflicts is normally not the best
+ solution when two packages provide the same files. Depending on
+ the reason for that conflict, using alternatives or renaming the
+ files is often a better approach. See, for
+ example, .
+
+ A Conflicts entry may have an "earlier than" version
+ clause if the reason for the conflict is corrected in a later
+ version of one of the packages. However, normally the presence
+ of an "earlier than" version clause is a sign
+ that Breaks should have been used instead. An "earlier
+ than" version clause in Conflicts
+ prevents
- If a relationship field has a version number attached
- then only real packages will be considered to see whether
- the relationship is satisfied (or the prohibition violated,
- for a conflict or breakage) - it is assumed that a real
- package which provides the virtual package is not of the
- "right" version. So, a Provides field may not
- contain version numbers, and the version number of the
- concrete package which provides a particular virtual package
- will not be looked at when considering a dependency on or
- conflict with the virtual package name.
+ If a relationship field has a version number attached, only real
+ packages will be considered to see whether the relationship is
+ satisfied (or the prohibition violated, for a conflict or
+ breakage). In other words, if a version number is specified,
+ this is a request to ignore all Provides for that
+ package name and consider only real packages. The package
+ manager will assume that a package providing that virtual
+ package is not of the "right" version. A Provides
+ field may not contain version numbers, and the version number of
+ the concrete package which provides a particular virtual package
+ will not be considered when considering a dependency on or
+ conflict with the virtual package name.
- It is likely that the ability will be added in a future
- release of
- If you want to specify which of a set of real packages
- should be the default to satisfy a particular dependency on
- a virtual package, you should list the real package as an
- alternative before the virtual one.
+ If the virtual package represents a facility that can only be
+ provided by one real package at a time, such as
+ the
- Firstly, as mentioned before, it is usually an error for a
- package to contain files which are on the system in
- another package.
+ It is usually an error for a package to contain files which
+ are on the system in another package. However, if the
+ overwriting package declares that it Replaces the one
+ containing the file being overwritten, then
- However, if the overwriting package declares that it
- Replaces the one containing the file being
- overwritten, then
@@ -4666,40 +4953,35 @@ Provides: bar
special argument to allow the package to do any final
cleanup required. See .
- Replaces is a one way relationship -- you have to
- install the replacing package after the replaced
- package.
-
For this usage of Replaces, virtual packages (see ) are not considered when looking at a - Replaces field - the packages declared as being + Replaces field. The packages declared as being replaced must be mentioned by their real names.
- Furthermore, this usage of Replaces only takes - effect when both packages are at least partially on the - system at once, so that it can only happen if they do not - conflict or if the conflict has been overridden. + This usage of Replaces only takes effect when both + packages are at least partially on the system at once. It is + not relevant if the packages conflict unless the conflict has + been overridden.
-- Secondly, Replaces allows the packaging system to + Second, Replaces allows the packaging system to resolve which package should be removed when there is a - conflict - see . This usage only - takes effect when the two packages do conflict, - so that the two usages of this field do not interfere with - each other. + conflict (see ). This usage only takes + effect when the two packages do conflict, so that the + two usages of this field do not interfere with each other.
@@ -4712,8 +4994,9 @@ Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent - ensuring that only one MTA can be installed at any one - time. + ensuring that only one MTA can be unpacked at any one + time. See for more information about this + example.
- If you make "build-arch" or "binary-arch", you need - Build-Depends. If you make "build-indep" or - "binary-indep", you need Build-Depends and - Build-Depends-Indep. If you make "build" or "binary", - you need both. -
There is no Build-Depends-Arch; this role is essentially - met with Build-Depends. Anyone building the - build-indep and binary-indep targets - is basically assumed to be building the whole package - anyway and so installs all build dependencies. The - autobuilders use dpkg-buildpackage -B, which - calls build (not build-arch, since it - does not yet know how to check for its existence) and - binary-arch. + met with Build-Depends. Anyone building the + build-indep and binary-indep targets is + assumed to be building the whole package, and therefore + installation of all build dependencies is required.
- The purpose of the original split, I recall, was so that - the autobuilders wouldn't need to install extra packages - needed only for the binary-indep targets. But without a - build-arch/build-indep split, this didn't work, since - most of the work is done in the build target, not in the - binary target. + The autobuilders use dpkg-buildpackage -B, which + calls build, not build-arch since it does + not yet know how to check for its existence, and + binary-arch. The purpose of the original split + between Build-Depends and + Build-Depends-Indep was so that the autobuilders + wouldn't need to install extra packages needed only for the + binary-indep targets. But without a build-arch/build-indep + split, this didn't work, since most of the work is done in + the build target, not in the binary target.
During install or upgrade, the preinst is called before
- the new files are installed, so calling "ldconfig" is
+ the new files are unpacked, so calling "ldconfig" is
pointless. The preinst of an existing package can also be
called if an upgrade fails. However, this happens during
the critical time when a shared libs may exist on-disk
@@ -5067,11 +5336,20 @@ Replaces: mail-transport-agent
- The development files associated to a shared library need to be
- placed in a package called
-
@@ -5080,7 +5358,7 @@ Replaces: mail-transport-agent ) to ensure that the user only installs one development version at a time (as different development versions are likely to have the same header files in them, which would cause a - filename clash if both were installed). + filename clash if both were unpacked).
@@ -6006,7 +6284,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
-@@ -6056,6 +6334,23 @@ rmdir /usr/local/share/emacs 2>/dev/null || true option.
+
+ Be careful of using set -e in
If a service reloads its configuration automatically (as
in the case of
@@ -7153,13 +7448,19 @@ strip --strip-unneeded your-lib
language currently used to implement it.
- Shell scripts (
+ Every script should use set -e or check the exit status
+ of every command.
Scripts may assume that
@@ -7753,15 +8056,12 @@ endscript
security policy by changing the permissions on a binary:
they can do this by using
If a program needs to specify an architecture specification
- string in some place, it should select one of the
- strings provided by dpkg-architecture -L. The
- strings are in the format
- os-arch, though the OS part
- is sometimes elided, as when the OS is Linux. Currently, the strings are:
- i386 ia64 alpha amd64 armeb arm hppa m32r m68k mips
- mipsel powerpc ppc64 s390 s390x sh3 sh3eb sh4 sh4eb
- sparc darwin-i386 darwin-ia64 darwin-alpha darwin-amd64
- darwin-armeb darwin-arm darwin-hppa darwin-m32r
- darwin-m68k darwin-mips darwin-mipsel darwin-powerpc
- darwin-ppc64 darwin-s390 darwin-s390x darwin-sh3
- darwin-sh3eb darwin-sh4 darwin-sh4eb darwin-sparc
- freebsd-i386 freebsd-ia64 freebsd-alpha freebsd-amd64
- freebsd-armeb freebsd-arm freebsd-hppa freebsd-m32r
- freebsd-m68k freebsd-mips freebsd-mipsel freebsd-powerpc
- freebsd-ppc64 freebsd-s390 freebsd-s390x freebsd-sh3
- freebsd-sh3eb freebsd-sh4 freebsd-sh4eb freebsd-sparc
- kfreebsd-i386 kfreebsd-ia64 kfreebsd-alpha
- kfreebsd-amd64 kfreebsd-armeb kfreebsd-arm kfreebsd-hppa
- kfreebsd-m32r kfreebsd-m68k kfreebsd-mips
- kfreebsd-mipsel kfreebsd-powerpc kfreebsd-ppc64
- kfreebsd-s390 kfreebsd-s390x kfreebsd-sh3 kfreebsd-sh3eb
- kfreebsd-sh4 kfreebsd-sh4eb kfreebsd-sparc knetbsd-i386
- knetbsd-ia64 knetbsd-alpha knetbsd-amd64 knetbsd-armeb
- knetbsd-arm knetbsd-hppa knetbsd-m32r knetbsd-m68k
- knetbsd-mips knetbsd-mipsel knetbsd-powerpc
- knetbsd-ppc64 knetbsd-s390 knetbsd-s390x knetbsd-sh3
- knetbsd-sh3eb knetbsd-sh4 knetbsd-sh4eb knetbsd-sparc
- netbsd-i386 netbsd-ia64 netbsd-alpha netbsd-amd64
- netbsd-armeb netbsd-arm netbsd-hppa netbsd-m32r
- netbsd-m68k netbsd-mips netbsd-mipsel netbsd-powerpc
- netbsd-ppc64 netbsd-s390 netbsd-s390x netbsd-sh3
- netbsd-sh3eb netbsd-sh4 netbsd-sh4eb netbsd-sparc
- openbsd-i386 openbsd-ia64 openbsd-alpha openbsd-amd64
- openbsd-armeb openbsd-arm openbsd-hppa openbsd-m32r
- openbsd-m68k openbsd-mips openbsd-mipsel openbsd-powerpc
- openbsd-ppc64 openbsd-s390 openbsd-s390x openbsd-sh3
- openbsd-sh3eb openbsd-sh4 openbsd-sh4eb openbsd-sparc
- hurd-i386 hurd-ia64 hurd-alpha hurd-amd64 hurd-armeb
- hurd-arm hurd-hppa hurd-m32r hurd-m68k hurd-mips
- hurd-mipsel hurd-powerpc hurd-ppc64 hurd-s390 hurd-s390x
- hurd-sh3 hurd-sh3eb hurd-sh4 hurd-sh4eb hurd-sparc
-
@@ -7949,6 +8208,27 @@ done
arch-unknown-linux, since the
unknown does not look very good.
+ A package may specify an architecture wildcard. Architecture
+ wildcards are in the format any (which matches every
+ architecture), os-any, or
+ any-cpu.
- 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 (versions 1.2 or 1.3) should refer to the corresponding
- files under
In particular,
-
The
@@ -9509,9 +9796,9 @@ END-INFO-DIR-ENTRY
- The maintainer scripts are guaranteed to run with a
- controlling terminal and can interact with the user.
- See .
+ The maintainer scripts are not guaranteed to run with a
+ controlling terminal and may not be able to interact with
+ the user. See .
The source archive scheme described later is intended to
- allow a Debianised source tree with some associated control
- information to be reproduced and transported easily. The
- Debianised source tree is a version of the original program
- with certain files added for the benefit of the
- Debianisation process, and with any other changes required
+ allow a Debian package source tree with some associated
+ control information to be reproduced and transported easily.
+ The Debian package source tree is a version of the original
+ program with certain files added for the benefit of the
+ packaging process, and with any other changes required
made to the rest of the source code and installation
scripts.
The extra files created for Debian are in the subdirectory
-
- See . -
- -- It is possible to use a different format to the standard - one, by providing a parser for the format you wish to - use. -
- -
- In order to have dpkg-parsechangelog run your
- parser, you must include a line within the last 40 lines
- of your file matching the Perl regular expression:
- \schangelog-format:\s+([0-9a-z]+)\W The part in
- parentheses should be the name of the format. For
- example, you might say:
-
- If such a line exists then dpkg-parsechangelog
- will look for the parser as
-
- The parser will be invoked with the changelog open on - standard input at the start of the file. It should read - the file (it may seek if it wishes) to determine the - information required and return the parsed information - to standard output in the form of a series of control - fields in the standard format. By default it should - return information about only the most recent version in - the changelog; it should accept a - -vversion option to return changes - information from all versions present strictly - after version, and it should then be an - error for version not to be present in the - changelog. -
- -
- The fields are:
-
-
-
- If several versions are being returned (due to the use - of -v), the urgency value should be of the - highest urgency code listed at the start of any of the - versions requested followed by the concatenated - (space-separated) comments from all the versions - requested; the maintainer, version, distribution and - date should always be from the most recent version. -
- -- For the format of the Changes field see - . -
- -- If the changelog format which is being parsed always or - almost always leaves a blank line between individual - change notes these blank lines should be stripped out, - so as to make the resulting output compact. -
- -- If the changelog format does not contain date or package - name information this information should be omitted from - the output. The parser should not attempt to synthesize - it or find it from other sources. -
- -- If the changelog does not have the expected format the - parser should exit with a nonzero exit status, rather - than trying to muddle through and possibly generating - incorrect output. -
- -- A changelog parser may not interact with the user at - all. -
-Apply the diff using patch -p0.
Untar the tarfile again if you want a copy of the original - source code alongside the Debianised version.
+ source code alongside the Debian version.
The source packaging tools manage the changes between the
- original and Debianised source using