Trying to replace courier with exim4 leaves the system in a broken state:

flatty:/etc# aptitude install exim4-daemon-light courier-mta- courier-base- courier-authdaemon- courier-authlib- courier-authlib-userdb-
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Reading task descriptions... Done
The following NEW packages will be installed:
  exim4-base{a} exim4-config{a} exim4-daemon-light
The following packages will be REMOVED:
  courier-authdaemon courier-authlib courier-authlib-userdb courier-base courier-mta
0 packages upgraded, 3 newly installed, 5 to remove and 0 not upgraded.
Need to get 1,859kB of archives. After unpacking 1,008kB will be freed.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
Get:1 http://ftp.de.debian.org squeeze/main exim4-config 4.71-4 [375kB]
Get:2 http://ftp.de.debian.org squeeze/main exim4-base 4.71-4 [1,007kB]
Get:3 http://ftp.de.debian.org squeeze/main exim4-daemon-light 4.71-4 [477kB]
Fetched 1,859kB in 2s (786kB/s)
[master ad2666e] saving uncommitted changes in /etc prior to apt run
 3 files changed, 9 insertions(+), 8 deletions(-)
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Preconfiguring packages ...
dpkg: courier-authlib: dependency problems, but removing anyway as you requested:
 courier-base depends on courier-authlib (>= 0.62.4).
 courier-authlib-userdb depends on courier-authlib (>= 0.63.0).
 courier-authdaemon depends on courier-authlib (>= 0.63.0).
(Reading database ... 44719 files and directories currently installed.)
Removing courier-authlib ...
dpkg: courier-mta: dependency problems, but removing anyway as you requested:
 bsd-mailx depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package mail-transport-agent is not installed.
  Package courier-mta which provides mail-transport-agent is to be removed.
  Package nullmailer which provides mail-transport-agent is not installed.
Removing courier-mta ...
Stopping Courier SMTP server: done.
Stopping Courier mail filter: done.
Stopping Courier mail server: done.
Removing `diversion of /usr/bin/addcr to /usr/bin/addcr.ucspi-tcp by courier-mta'
Removing `diversion of /usr/share/man/man1/addcr.1.gz to /usr/share/man/man1/addcr.ucspi-tcp.1.gz by courier-mta'
Removing courier-base ...
Removing courier-authdaemon ...
Stopping Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "stop" failed.
dpkg: error processing courier-authdaemon (--remove):
 subprocess installed pre-removal script returned error exit status 126
Starting Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 126
Removing courier-authlib-userdb ...
Processing triggers for man-db ...
Errors were encountered while processing:
 courier-authdaemon
[master 43de7c1] committing changes in /etc after apt run
 15 files changed, 11 insertions(+), 33 deletions(-)
 delete mode 120000 alternatives/deliverquota
 delete mode 120000 alternatives/deliverquota.8.gz
 delete mode 120000 alternatives/lockmail
 delete mode 120000 alternatives/lockmail.1.gz
 delete mode 120000 alternatives/maildir.5.gz
 delete mode 120000 alternatives/maildirmake
 delete mode 120000 alternatives/maildirmake.1.gz
 delete mode 120000 alternatives/maildirquota.7.gz
 delete mode 120000 alternatives/makedat
 delete mode 120000 alternatives/makedat.1.gz
 delete mode 120000 alternatives/preline
 delete mode 120000 alternatives/preline.1.gz
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done

Current status: 2 broken [+2].
flatty:/etc#


Subsequent attempts remove some auto-installed packages, but don't recover from the broken state:

flatty:/etc# dpkg -a --configure
flatty:/etc# aptitude install exim4-daemon-light courier-mta- courier-base- courier-authdaemon- courier-authlib- courier-authlib-userdb-
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done
The following NEW packages will be installed:
  exim4-base{a} exim4-config{a} exim4-daemon-light
The following packages will be REMOVED:
  courier-authdaemon{u} expect{u} libfam0{u} tcl8.5{u}
0 packages upgraded, 3 newly installed, 4 to remove and 0 not upgraded.
Need to get 0B/1,859kB of archives. After unpacking 1,237kB will be freed.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Preconfiguring packages ...
(Reading database ... 44519 files and directories currently installed.)
Removing courier-authdaemon ...
Stopping Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "stop" failed.
dpkg: error processing courier-authdaemon (--remove):
 subprocess installed pre-removal script returned error exit status 126
Starting Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 126
Removing expect ...
Removing libfam0 ...
Removing tcl8.5 ...
Processing triggers for man-db ...
Errors were encountered while processing:
 courier-authdaemon
[master a01b8f8] committing changes in /etc after apt run
 2 files changed, 0 insertions(+), 2 deletions(-)
 delete mode 120000 alternatives/tclsh
 delete mode 120000 alternatives/tclsh.1
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done

flatty:/etc# aptitude install exim4-daemon-light courier-mta- courier-base- courier-authdaemon- courier-authlib- courier-authlib-userdb-
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done
The following NEW packages will be installed:
  exim4-base{a} exim4-config{a} exim4-daemon-light
The following packages will be REMOVED:
  courier-authdaemon{u}
0 packages upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 0B/1,859kB of archives. After unpacking 3,781kB will be used.
Do you want to continue? [Y/n/?]
Writing extended state information... Done
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Preconfiguring packages ...
(Reading database ... 44239 files and directories currently installed.)
Removing courier-authdaemon ...
Stopping Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "stop" failed.
dpkg: error processing courier-authdaemon (--remove):
 subprocess installed pre-removal script returned error exit status 126
Starting Courier authentication services: authdaemond/usr/sbin/authdaemond: line 18: /usr/sbin/courierlogger: No such file or directory
/usr/sbin/authdaemond: line 18: exec: /usr/sbin/courierlogger: cannot execute: No such file or directory
invoke-rc.d: initscript courier-authdaemon, action "start" failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 126
Errors were encountered while processing:
 courier-authdaemon
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information... Done
Initializing package states... Done
Writing extended state information... Done
Reading task descriptions... Done


Any idea how to un-break my system?

I've worked around this by killing the remaining courier processes
manually ("pkill -f courier") and hacking
/var/lib/dpkg/info/courier-authdaemon.prerm to do "exit 0" immediately.
Courier is now gone from my system.

CU Sascha

OK, thanks for the information.

Regards
	Racke

SETUP::

	aptitude install exim4-base- exim4-config- exim4-daemon-light- courier-mta courier-base courier-authdaemon courier-authlib courier-authlib-userdb bsd-mailx

REPRODUCE BUG::

	aptitude install exim4-daemon-light courier-mta- courier-base- courier-authdaemon- courier-authlib- courier-authlib-userdb-

UGLY LOCAL FIX::

	sed -i'' 's/exit \$?/exit 0/' /var/lib/dpkg/info/courier-authdaemon.prerm
	aptitude install -f


In order to reproduce the bug bsd-mailx must be installed. bsd-mailx depends on
a mail-transport-agent which is provided by courier-mta.

On deinstallation (with bsd-mailx installed) courier-authlib is removed
first, if bsd-mailx is installed. However courier-authdaemon depends on
courier-authlib (which ships /usr/sbin/courierlogger) and cannot be
installed anymore.

/usr/sbin/courierlogger is called (via authdaemond) from the
courier-authdaemon.prerm skript. The policy requires that all programms
called from courier-authdaemon.prerm are still installed.

Thus for me it seems that aptitude is not deinstalling the packages in the
right order. If bsd-mailx is installed the order is::

	remove courier-authlib 0.63.0-2 0.63.0-2
	remove courier-mta 0.65.0-1 0.65.0-1
	remove courier-base 0.65.0-1 0.65.0-1
	remove courier-authdaemon 0.63.0-2 0.63.0-2

which then breaks.


Regards,
Moritz

update: I tried the same with apt-get with the same result.

Regards,
Moritz

reassig 579790 dpkg
affects 579790 courier-authdaemon

thanks

aptitude calls dpkg with the following options (strace):

/usr/bin/dpkg --status-fd 11 --force-depends --force-remove-essential --remove courier-mta courier-base courier-authdaemon courier-authlib-userdb courier-authlib

However courier-authlib is deinstalled first which breaks the
deinstallation process as explained in 579790.

Dpkg should not reorder the package deinstallation when called with
the --force-depends option.


Regards,
Moritz

severity 579790 important
quit

Hi Moritz,

Moritz Beyreuther wrote:

exim is being installed to replace courier-mta as mail-transfer-agent.
As you mentioned, bsd-mailx depends on an mta, so there is apparently
no clean way to do this and the frontend passes a --force-* option.
So now from the point of view of dpkg we are outside the realm of
policy and in my opinion no matter what happens it is not going to be
intuitive.

There is a way around that, which is to use the --auto-deconfigure
option.  It should be able to produce a saner sequence of operations:

 1. deconfigure everything that needs an mta
 2. remove courier-mta
 3. remove the packages courier-mta depended on

Just my two cents.  See also http://bugs.debian.org/501866 which is
about circular dependencies rather than external ones.

Thanks for the report,
Jonathan

Jonathan Nieder wrote:

More thoughts.

1. --force-depends makes semantics hard to reason about, but the
   algorithm is actually very simple (from src/packages.c):

| The criteria for satisfying a dependency vary with the various
| tries.  In try 1 we treat the dependencies as absolute.  In try 2 we
| check break any cycles in the dependency graph involving the package
| we are trying to process before trying to process the package
| normally.  In try 3 (which should only be reached if
| --force-depends-version is set) we ignore version number clauses in
| Depends lines.  In try 4 (only reached if --force-depends is set) we
| say "ok" regardless.

   In this case, all the packages to be removed are are indirect
   dependencies of mailx.  So indeed your analysis
   was right; the first package removed is practically random.

2. In case this is not fixed before squeeze, there is a question of
   what to do about courier-authdaemon.  Is it possible for its prerm
   to carry out its work “by hand” if courier-authlib is missing?

3. I really do wish frontends would use --auto-deconfigure in cases like
   this, but probably there is some fatal flaw I am missing.  Hints?

4. To address this in dpkg, one way would be to insert a pass 3.5
   which pays attention only to direct dependencies between the
   packages to be installed or removed.  Imagine dependencies

       mailx -> courier-mta -> C -> courier-base

   and a person runs

       dpkg --force-depends --remove courier-mta courier-base.

   According to this heuristic, it is arbitrary whether courier-mta
   or courier-base gets removed first (since neither depends on the
   other).

   However, if we take into account indirect dependencies of packages
   to be installed or removed, the result starts to look saner.

Hope that helps.

Ciao Jonathan,

thanks for your fast reply, not sure that I got it right. The
following does not do the job::

    dpkg --auto-deconfigure --force-depends --force-remove-essential \
        --remove courier-mta courier-base courier-authdaemon \
        courier-authlib-userdb courier-authlib

However, if I force the order manually, it works::

    dpkg --force-depends --force-remove-essential --remove courier-mta
    dpkg --force-depends --force-remove-essential --remove courier-base \
        courier-authdaemon courier-authlib-userdb courier-authlib

Shouldn't this still be a bug in dpkg because it render the order arbitrary?

One solution of this problem on the courier side could be
(similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=262887)::

1.) stopping the authdaemond daemon in a courier-authlib "postrm remove"
2.) change the /etc/init.d/courier-authdaemon script that it does not
    stop the authdaemon, if it is already stopped or if the
    courier-authlib package is not installed


Regards,
Moritz

Moritz Beyreuther wrote:

What happens when you leave out the --force- options?

Yes, it’s a bug (or at least there’s room for improvement).  I was
just saying policy doesn’t explain what should happen here.

It results in the following:
$ dpkg --auto-deconfigure --remove courier-mta courier-base courier-authdaemon courier-authlib-userdb courier-authlib
dpkg: dependency problems prevent removal of courier-mta:
 bsd-mailx depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package exim4-daemon-light which provides default-mta is not installed.
  Package mail-transport-agent is not installed.
  Package courier-mta which provides mail-transport-agent is to be removed.
  Package exim4-daemon-light which provides mail-transport-agent is not installed.
dpkg: error processing courier-mta (--remove):
 dependency problems - not removing
dpkg: dependency problems prevent removal of courier-base:
 courier-mta depends on courier-base (>= 0.65.0).
alright, I understand.


Regards,
Moritz

# [1]
severity 579790 serious
quit

Moritz Beyreuther wrote:

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.

Yes I also think this is a solution.

However it might be easier to change the following behavior:
It might be better to not "arbitrarily" remove one of the packages
first, but to remove the one which the program/user specified first.
Thus assuming that the program/user actually knows what it/he does.


Regards,
Moritz

[ This is actually something I've had in my list of things to discuss
  with frontends, so here it goes, through a bug report. :) ]

Nope, the correct way to go about this is to setup a “dpkg transaction”
through selections, which tells explicitly to dpkg what can be done,
avoids the extra scary message from dpkg, gets a better result,
minimizes the time packages have been forced out of the way, and
avoids --force-* options.

In this case apt would do, the equivalent of:

  # cat <<TRANS | dpkg --set-selections
  courier-mta deinstall
  courier-base deinstall
  courier-authdaemon deinstall
  courier-authlib-userdb deinstall
  courier-authlib deinstall
  TRANS
  # dpkg --auto-deconfigure --install exim*.deb
  # dpkg --remove --pending

or something similar. In general apt should really not be forcing
removals on dpkg, it should tell dpkg what packages are fine to
remove, and then do a final remove, that would also reduce the number
of transactions needed for an upgrade.

The only --force option that a frontend should be “justified” to use
at all is --force-remove-essential, only when the user has acknowledged
that explicitly through a prompt or similar, and only then, not passed
blindly on all invocations.

In general, any time a frontend is using a --force option, there's
something wrong going on.

Using selections is how dselect has managed to work all this time w/o
the need for any --force option at all.

Thanks,
Guillem

*Sehr geehrte Damen und Herren, beantragen Sie ein schnelles und bequemes
Darlehen zur Begleichung von Rechnungen. Benötigen Sie Mittel, um ein
Unternehmen zu gründen, um sich jetzt zu bewerben und mit einem Zinssatz
von 2% genehmigt zu werden? Wir bieten alle Arten von Darlehen,
Investitionen, Projektfinanzierung und geben auch finanzielle Unterstützung
für Einzelpersonen, Körperschaften und Unternehmen weltweit. Für weitere
Informationen zu unserem Angebot kontaktieren Sie uns bitte per E-Mail:
info@mail-customercaremarketing.com <info@mail-customercaremarketing.com>*
*Freundliche Grüße*

 Hallo,

Ich bin Azim Hashim Premji, ein indischer Wirtschaftsmagnat, Investor und
Philanthrop. Ich bin der Vorsitzende von Wipro Limited. Ich gab 25 Prozent
meines persönlichen Vermögens für wohltätige Zwecke ab. Und ich habe auch
versprochen, den Rest von 25% in diesem Jahr 2020 an Einzelpersonen zu
verschenken. Ich habe beschlossen, 50.000,00 USD an Sie zu spenden. Wenn
Sie an meiner Spende interessiert sind, kontaktieren Sie mich für weitere
Informationen: azimhashim54@gmail.com

Sie können auch mehr über mich über den Link unten lesen

http://en.wikipedia.org/wiki/A zim_Premji

Herzlicher Gruss
Geschäftsführer Wipro Limited
Azim Hashim Premji

Bitte kontaktieren Sie Herrn Alvin Walker für weitere Informationen zu
Ihrem Geldtransfer unter alvinwalker181@gmail.com

Bitte kontaktieren Sie Herrn Alvin Walker für weitere Informationen zu
Ihrem Geldtransfer unter alvinwalker181@gmail.com