From ea7b78163e560dd646e5aea079d2e59163ea4e07 Mon Sep 17 00:00:00 2001 From: Russ Allbery Date: Mon, 26 Jul 2010 14:39:49 -0700 Subject: [PATCH] Further improvements to maintainer script state requirements Based on further feedback from Steve Langasek and Jonathan Nieder. --- policy.sgml | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/policy.sgml b/policy.sgml index 3c63507..9e8689e 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3809,7 +3809,11 @@ Checksums-Sha256: dependencies may not be available. Pre-dependencies will be at least unpacked following the same rules as above, except they may be only "Half-Installed" if an upgrade of the - pre-dependency failed. + pre-dependency failed. + This can happen if the new version of the package no + longer pre-depends on a package that had been partially + upgraded. +

@@ -4613,11 +4617,19 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

Since Depends only places requirements on the order in which packages are configured, packages in an installation run - are usually all unpacked first and all configured later. This - allows multiple packages to be upgraded in one unpack and - configure step even if some packages being upgraded have - versioned dependencies on the upgraded versions of other - packages involved in the installation run. + are usually all unpacked first and all configured later. + + This approach makes dependency resolution easier. If two + packages A and B are being upgraded, the installed package A + depends on exactly the installed package B, and the new + package A depends on exactly the new package B (a common + situation when upgrading shared libraries and their + corresponding development packages), satisfying the + dependencies at every stage of the upgrade would be + impossible. This relaxed restriction means that both new + packages can be unpacked together and then configured in their + dependency order. +

@@ -4668,8 +4680,9 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] dependency loop, this might not work as expected; see the explanation a few paragraphs back.) In the case of prerm or other postinst - actions, the package dependencies will be at least - unpacked or "Half-Installed". + actions, the package dependencies will normally be at + least unpacked, but they may be only "Half-Installed" if a + previous upgrade of the dependency failed.

@@ -4830,10 +4843,10 @@ 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 unpacked on the system at the same time. This - is a stronger restriction than Breaks, which only - prevents both packages from being configured at the same time. - Conflicting packages cannot be unpacked on the system at the - same time. + is a stronger restriction than Breaks, which prevents + the broken package from being configured while the breaking + package is in the "Unpacked" state but allows both packages to + be unpacked at the same time.

@@ -4887,7 +4900,7 @@ Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any] when two packages provide the same file and will continue to do so, in conjunction with Provides when only one - package providing a given virtual facility may be installed + package providing a given virtual facility may be unpacked at a time (see ), in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing -- 2.39.2