[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pre-Depends: dpkg (>= for dpkg-maintscript-helper okay?


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

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


  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,

Reply to: