Jonathan Nieder wrote:
> severity 579790 important
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.
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
