From: Russ Allbery Date: Tue, 29 Jun 2010 18:14:49 +0000 (-0700) Subject: Merge branch 'master' into bug504880-rra X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=21df36b8215e66ff6a1f66de5418660dc032df99;hp=30daa4aab845a7972bff3f0e33994176bc912dc6;p=debian%2Fdebian-policy.git Merge branch 'master' into bug504880-rra --- diff --git a/policy.sgml b/policy.sgml index 9fe7158..2f4c935 100644 --- a/policy.sgml +++ b/policy.sgml @@ -1058,8 +1058,8 @@

- 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.

@@ -3653,7 +3653,7 @@ Checksums-Sha256:

Broadly speaking the preinst is called before - (a particular version of) a package is installed, and the + (a particular version of) a package is unpacked, and the postinst afterwards; the prerm before (a version of) a package is removed and the postrm afterwards. @@ -4043,7 +4043,7 @@ Checksums-Sha256: behavior which, though deterministic, is hard for the system administrator to understand. It can easily lead to "missing" programs if, for example, a package - is installed which overwrites a file from another + is unpacked which overwrites a file from another package, and is then removed again. Part of the problem is due to what is arguably a bug in dpkg. @@ -4179,7 +4179,7 @@ Checksums-Sha256: If there was a conflicting package we go and do the removal actions (described below), starting with the removal of the conflicting package's files (any that - are also in the package being installed have already + are also in the package being unpacked have already been removed from the conflicting package's file list, and so do not get removed now). @@ -4493,31 +4493,30 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

- 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 + postinst script, then the cycle will be broken at + that package; this ensures that all postinst + scripts are run with their dependencies properly configured if + this is possible. Otherwise the breaking point is arbitrary. + Packages should therefore avoid circular dependencies where + possible, particularly if they have postinst + scripts.

@@ -4529,7 +4528,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] 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).

@@ -4543,10 +4543,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] The Depends field should also be used if the postinst, prerm or postrm scripts require the package to be - present in order to run. Note, however, that the - postrm cannot rely on any non-essential - packages to be present during the purge - phase. + present in order to run. (If both packages are involved + in a dependency loop, this might not work as expected; see + the explanation a few paragraphs back.) In the case of + postinst and postrm, the + depended-on packages will be unpacked and configured + first. (Note, however, that the postrm + cannot rely on any non-essential packages to be present + during the purge phase.) In the case of + prerm, the depended-on package will at least + be unpacked (it might be configured too, but you can't + rely on this unless you use Pre-Depends). Recommends @@ -4609,7 +4616,17 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] to be configured, the pre-dependency will be treated as a normal Depends, that is, it will be considered satisfied only if the depended-on - package has been correctly configured. + package has been correctly configured. However, unlike + with Depends, Pre-Depends does not + permit circular dependencies to be broken. If a circular + dependency is encountered while attempting to honor + Pre-Depends, the installation will be aborted. +

+ +

+ Pre-Depends are also required if the + preinst script depends on the named package. + It is best to avoid this situation if possible.

@@ -4618,13 +4635,6 @@ 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.

- -

- Pre-Depends are also required if the - preinst script depends on the named - package. It is best to avoid this situation if - possible. -

@@ -4649,7 +4659,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

When one binary package declares that it breaks another, dpkg will refuse to allow the package which - declares Breaks be installed unless the broken + declares Breaks be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured.

@@ -4702,7 +4712,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

When one binary package declares a conflict with another using a Conflicts field, dpkg will - refuse to allow them to be installed on the system at the + refuse to allow them to be unpacked on the system at the same time. This is a stronger restriction than Breaks, which just prevents both packages from being configured at the same time. Conflicting packages cannot be unpacked on the @@ -4710,8 +4720,8 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

- If one package is to be installed, the other must be removed - first. If the package being installed is marked as replacing + If one package is to be unpacked, the other must be removed + first. If the package being unpacked is marked as replacing (see , but note that Breaks should normally be used in this case) the one on the system, or the one on the system is marked as deselected, or both packages are @@ -4984,7 +4994,7 @@ Provides: mail-transport-agent Conflicts: mail-transport-agent Replaces: mail-transport-agent - ensuring that only one MTA can be installed at any one + ensuring that only one MTA can be unpacked at any one time. See for more information about this example. @@ -5203,7 +5213,7 @@ Replaces: mail-transport-agent

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 @@ -5348,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).

@@ -9687,7 +9697,7 @@ END-INFO-DIR-ENTRY

The DEBIAN directory will not appear in the file system archive of the package, and so won't be installed - by dpkg when the package is installed. + by dpkg when the package is unpacked.