Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?
Hi,
Steve Langasek wrote:
> So in this case the pre-dependency
> should *not* be set, as it only serves to complicate the upgrade path.
I think this example might deserve a closer look. Documentating the
required dpkg version seems useful for backporters and others who
would use the package in unusual situations.
What dpkg does:
Since depisok() is called with allowunconfigd == true, to dpkg a
Pre-Depends is just like a Depends, except that at unpack time dpkg
checks that the depended-on package:
- has been configured before
- satisfied the version relation the last time it was configured
- has not been removed since then.
These conditions are trivially satisfied when unpacking a package in
wheezy. The pre-dependency would have no effect beyond a Depends
relation (and in particular, would be safe).
What apt, aptitude do:
I don't know. Do they allow an already satisfied Pre-Depends to
complicate the upgrade path? IIRC dpkg, as an essential package,
always gets upgraded first anyway, but I am not so familiar with this
code.
What policy allows package managers to do:
Policy is aligned with what dpkg currently does.
What future policy allows:
Bug#593177 brings the possibility of change. In the extreme case the
meaning of Pre-Depends could change to "the depended-on package and
its dependencies must be configured at the currently unpacked
version", which would make upgrade impossible in the following case.
- libc6: Pre-Depends: dpkg (>= ancient).
- dpkg: Pre-Depends: libc6.
Luckily, bug#593177 can probably be addressed with less dramatic
changes.
Conclusions:
I could go either way on this. On one hand, versioned Pre-Depends
on essential packages in the previous release's version seem to be
harmless with current tools. On the other hand, as Steve mentioned,
decreasing the number of pre-dependencies in the archive is good for
everyone's sanity.
Hope that helps,
Jonathan
Reply to: