[Have cc'd some of the people whose postings are referred to. Since they didn't ask to be cc'd, I've left them out of the Mail-followup-to header; they can follow debian-policy if they're interested in the subject.]
On Sat, Jan 12, 2002 at 06:23:54PM +0000, Julian Gilbey wrote: > According to a recent post by Wichert to -devel, a cyclic dependency > is allowed, but all of the packages in the cycle have to be configured in > the same dpkg invocation. Thanks, Julian. For other people reading debian-policy, below I've summarised relevant posts from that thread. The thread begins at http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01329.html where someone says it would be useful if he could ensure that a particular pair of packages' postinst scripts run in a particular order. Adam Heath voices what is I believe the natural reading of current policy, namely that Depends implies postinst ordering, and consequently that dependency cycles aren't allowed. http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01392.html Adam wrote some of dpkg's cycle-breaking code, so presumably his words here should be taken as his interpretation of policy rather than dpkg behaviour. This is evidence that current policy wording is giving developers false confidence that Depends is sufficient to ensure an ordering among postinst runs. A different script to find cycles (including graphing the output) can be found at http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01902.html Also contains reference to a short thread on the subject of cycles and similar, including their uses. Thread begins at: http://lists.debian.org/debian-devel/2001/debian-devel-200112/thrd4.html#01737 Wichert, saying simply what Julian has reported: http://lists.debian.org/debian-devel/2001/debian-devel-200112/msg01905.html There are no further messages in the thread. Summary: Current wording of policy does not reflect actual practice of dpkg, and gives false confidence that Depends implies postinst ordering. There are many cases where a package A requires other packages B in order for A to run, but where A does not need B to be configured before A is configured. Current version of dpkg (1.9.18) does attempt to do configuration in the order implied by Depends (apparently using an O(n**2) algorithm): see main/configure.c. We do not yet know how often (if at all) packages need an order guarantee among their postinst scripts; fetchmail (see above href) may be an example. (Have cc'd fetchmail maintainer, since his packages may be affected by this policy matter.) If we assume that Depends cycles are allowed, then there is no way currently of declaring the relationship that B must be already configured (postinst run etc.) before A is configured. Pre-Depends provides a stronger guarantee, but not necessarily in a superset sense: the current description of Pre-Depends in policy says that it is treated like a normal Depends for configuration, which we've just said does not provide the configuration ordering guarantee. (Seems to be confirmed by looking at the dpkg source; I find no evidence of pre-depends even being given precedence when trying to break cycles.) A "minimalist" resolution is for policy simply to describe current dpkg behaviour, namely that Depends guarantees ordering of configuration unless there is a cycle; and that if there is a cycle then pre-depends doesn't even get precedence when breaking the cycle. A disadvantage is that there is no way to declare that your package really does require postinst ordering, so easier for bugs to appear (changes in other packages dependency lists can remove the guarantee you thought you had), and not generally possible to detect problems. A response to the above disadvantage is to explicitly say that packages must not make any assumptions about the order in which packages are configured. Either now or after someone has demonstrated a need, a Config-Depends and/or Run-Depends field could be introduced, which explicitly do / do not (respectively) provide an order guarantee. This at least allows people to say what they mean, thus facilitating analysis, and allowing problems to be averted. An initial dpkg implementation could be simply to treat as synonyms for existing Depends (i.e. just add a line to nicknames[] in lib/parsehelp.c), with full implementation waiting until there exists a cycle that doesn't consist entirely of Run-Depends. (Obviously document the situation wrt dpkg implementation.) If a Run-Depends field is introduced, then file a minor bug against each package currently in a cycle, requesting that at least one package (preferably each package) of the cycle use Run-Depends (and stating the situation wrt dpkg implementation). When updating the description of Depends, note that Pre-Depends is currently defined partly in terms of what Depends means; that text probably needs updating at the same time as updating the Depends description. pjm.
