Bug#128868: debian-policy: Depends semantics unclear re circular depends

[Peter Moulder <pmoulder@csse.monash.edu.au>]

On Mon, Jan 14, 2002 at 11:06:22AM +0100, Wichert Akkerman wrote:
> Previously Peter Moulder wrote:
> > 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.
> 
> I'm not convinced the circular dependency is needed here, and in fact
> the current package does not have one.

Please re-read the above paragraph.  No-one has claimed that a circular
dependency is needed.

> > 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.
> 
> Well, they are allowed but as soon as you create a cycle it will have
> to be broken so you can't assume an exact ordering anymore.

They are allowed by dpkg, whereas current policy says that they are not
allowed, hence giving false confidence that no cycles will occur and thus
that one's Depends line will always be honoured wrt ordering of
configuration, which may turn out not to be guaranteed if a cycle exists,
even if no such cycle exists at the time one releases one's package.

> > 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.
> 
> How common? I'm not quite convinced it is common. Also a lot of those
> cases can be rewritten to use Conflicts instead of Depends.

Please re-read the above paragraph.  It merely describes the usual case
when Depends are used.  In case my wording above is unclear, I'll try to
re-phrase it:

  There are many examples of where some package (let's call it `A')
  requires some other package (let's call it `B') to be installed and
  configured before package A is actually used by users, while not
  actually having any requirements about the order in which A and B are
  configured.

Slightly more mathematically:

  There are many examples of pairs (A,B) such that:
    - A is a package.
    - B is a package.
    - In order for A to be usefully be used at time T by users on a given
      system S, B must be in an installed & configured state on S.
    - It doesn't matter whether A is configured before B, or B is
      configured before A.

For example, vim requires libncurses5 to be installed & configured before
people can run vim, but vim's postinst doesn't invoke vim (or any other
program using libncurses5) (and nor of course is libncurses5's postinst
affected by vim's postinst), so it doesn't matter whether vim or
libncurses5 is configured first.  So the pair (vim,libncurses5) is an
example.

pjm.