From: Russ Allbery Date: Sat, 14 Feb 2009 02:36:59 +0000 (-0800) Subject: Rewordings of the description of Depends and Pre-Depends X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=4a52cc805af11439d8005c2f4c65e2eef50ed51a;p=debian%2Fdebian-policy.git Rewordings of the description of Depends and Pre-Depends Reword the discussion of Depends, Pre-Depends, and circular dependencies. Document that Pre-Depends doesn't allow circular dependencies and improve the documentation of what Depends guarantees for postinst and prerm scripts. Clarify the implications of circular dependencies and recommend against them. Reorder some of the Pre-Depends discussion. --- diff --git a/policy.sgml b/policy.sgml index f5c6818..f4c16ab 100644 --- a/policy.sgml +++ b/policy.sgml @@ -4273,31 +4273,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. -

- -

- 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 unpacked when being - unpacked 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. + 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. +

+ +

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

@@ -4309,7 +4308,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).

@@ -4323,10 +4323,17 @@ Build-Depends: foo [!i386] | bar [!amd64] 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 @@ -4389,7 +4396,17 @@ Build-Depends: foo [!i386] | bar [!amd64] 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.

@@ -4398,13 +4415,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 - preinst script depends on the named - package. It is best to avoid this situation if - possible. -