Bug#128868: debian-policy: Depends semantics unclear re circular depends
[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.
Reply to: