On Tue, Jan 26, 2010 at 01:11:19PM -0800, Russ Allbery <r...@debian.org> was heard to say: > > The mechanism exists to do a non-mutative upgrade calculation, I just > > hadn't hooked it up to the command-line. That could solve half the > > problem. I'd also like to see why the resolver isn't just canceling the > > automatic removal -- that ought to be preferred to installing a new > > package. > > Thank you for the update! The explanation makes a lot of sense.
I tracked down one bug that was part of this: aptitude was incorrectly treating the automatic removal as a "manual" action, so it was penalizing solutions that restore the package. However, in at least one of the two cases that's involved, it still tries to switch to the other console-setup package, because it solves more outstanding dependencies than the alternative, so it looks like a locally better solution. Probably an argument for tracking down those algorithms to split a constraint graph and work on it piecewise... I might wait a bit on rewiring the upgrade commands. It'll require a bunch of coding, and I suspect that it won't actually fix all the problems (there are probably cases where aptitude would get confused and start fixing dependencies of stuff that was going to be removed anyway). The real fix here is to integrate autoremoval into the dependency solver, so it knows exactly what the outcomes of its actions are. Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
