X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=policy.sgml;h=74f94e8c4665de20ad3cd09454f50943c70791b7;hb=6b5ecb49b116555668ebdfc97d9586d5697bb6a8;hp=7c223101cea76fa78dffb94849d33ca15993f9f7;hpb=ccf06874887cff69d4c6b8ae6a603e1a351b24d3;p=debian%2Fdebian-policy.git diff --git a/policy.sgml b/policy.sgml index 7c22310..74f94e8 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1618,11 +1618,38 @@
- The date must be in RFC822 format
+
@@ -1761,7 +1788,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
@@ -1827,21 +1854,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.
@@ -2370,6 +2404,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. @@ -2454,8 +2493,6 @@ Package: libc6 The syntax and semantics of the fields are described below.
- -
These fields are used by
+ The structure of the Debian changes files is versionned, and + this document describes the format 1.8. +
+
The fields in this file are:
@@ -2529,15 +2571,17 @@ 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).
@@ -2649,17 +2695,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
@@ -3200,7 +3248,9 @@ Package: libc6
- 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
@@ -3214,13 +3264,25 @@ 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
+ 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
+ This field is similar to the
+ This field is similar to the
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.
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
-
@@ -4607,12 +4749,52 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]
- 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
@@ -4726,40 +4952,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.
@@ -4773,7 +4994,8 @@ Conflicts: mail-transport-agent Replaces: mail-transport-agent ensuring that only one MTA can be installed at any one - time. + 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.
- The development files associated to a shared library need to be
- placed in a package called
-
@@ -6958,7 +7175,7 @@ exec /usr/lib/foo/foo "$@"
@@ -7503,6 +7720,8 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
package is purged.
+ Obsolete configuration files without local changes may be
+ removed by the package during upgrade.
@@ -8923,7 +9142,7 @@ name ["syshostname"]:
name="Man-Page-HOWTO">,
- 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 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
- Apply the diff using patch -p0. Untar the tarfile again if you want a copy of the original
- source code alongside the Debianised version.
The source packaging tools manage the changes between the
- original and Debianised source using