# [1]
severity 579790 serious
quit

Moritz Beyreuther wrote:
> On Sat, Jul 17, 2010 at 08:56:51AM -0500, Jonathan Nieder wrote:
>> Moritz Beyreuther wrote:

> dpkg: dependency problems prevent removal of courier-mta:

Oh, right; --auto-deconfigure only applies to Conflicts and Breaks,
not newly unsatisfied reverse-Depends (another variant on Bug#20471).
Sorry to mislead.

Okay, thanks for the explanations.  What’s left is a simple matter
of coding, I think.  Summary follows.

-------

Let’s distill this to a simplified example:

 bsd-mailx: Depends: mail-transport-agent
 courier-mta: Provides: mail-transport-agent
 exim4: Provides: mail-transport-agent
 courier-mta: Depends: courier-authlib

Suppose bsd-mailx, courier-mta, and courier-authlib are installed
and the user wants to switch to exim.  Then both apt and aptitude
will try

 dpkg --force-many-things --remove courier-authlib courier-mta
 dpkg --force-many-things --install exim4.deb

The first of these two commands has a counterintuitive effect:
because none of the packages listed are safe to remove, dpkg
says “oh, screw it” and picks one _arbitrarily_ to remove first.
If that is courier-authlib, then when it is time to remove
courier-mta, its dependencies won’t be satisfied, and prerm will
fail.

What is dpkg supposed to do?  Ensuring all dependencies are
satisfied for prerm in the presence of an arbitrary collection
of missing packages is impossible.

But if dpkg can rely on the frontend to not remove any dependencies
of the packages to be removed, the procedure is simple.

  try 1: find a package with no reverse-depends.  remove it.

  if that fails: find a package with no reverse-depends after
                 breaking cyles and remove that.

  if no cycles: find a package with no indirect reverse-depends
                among the packages to be removed.  remove it.

  if that fails: find a package with no reverse-depends,
                 ignoring versions[2], and remove that.

  if that fails: find a package with no indirect reverse-depends,
                 among the packages to be removed, ignoring
                 versions[2], and remove that.

  if that fails: remove an arbitrary package.

Time to sleep.  Thanks again.
Jonathan

[1] Policy 7.2 says:

     The Depends field should also be used if the postinst, prerm or
     postrm scripts require the package to be present in order to run.
     Note, however, that the postrm cannot rely on any non-essential
     packages to be present during the purge phase.

and packages are right to rely on that.  So it seems right to
consider this release-critical after all.

[2] e.g. if bsd-mailx had Depends: mail-transport-agent | sed (>= 200)
this would give an escape valve.




-- 
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to