On Tue, Feb 09, 2010 at 09:16:06AM +0900, Miles Bader <[email protected]> was heard to say: > For a while it seemed like aptitude 0.6.1.5 was finally a version that > would calm all the complaints people have about aptitude wildly deleting > half their system. > > But... lately it seems like _every time_ there's some conflict, > aptitude's first (and thus default, if you don't explicitly try to find > another) solution is to delete a bunch of packages, rather than holding > back one or two from being upgraded.
I tried to avoid this by making aptitude only remove packages if there was no alternative. The problem was, this broke other perfectly reasonable upgrade scenarios. I think that I'm going to have to implement some stronger optimization logic in the solver, which I'm working on now. It'll probably take a few passes to make it efficient enough at solving this problem, though. It turns out that contrary to my initial thought, things like minimizing the number of removals are not a trivial extension of the existing framework -- not if some obvious "bad" behavior is to be avoided, anyway. > Part of the problem, of course, is the fact that aptitude's interactive > behavior (at least, the conflict resolution that happens when you hit > "g" in the interactive session), for whatever reason, apparently > corresponds to "aptitude dist-upgrade" from the command-line, rather > than "aptitude upgrade". This seems vaguely bizarre to me (isn't > dist-upgrade'ing an extremely rare occurance?), but maybe there are > historical reasons, I dunno. The interactive resolution behavior just tries to solve dependencies. It doesn't know whether you're upgrading, installing new packages, or removing stuff. The command-line has the advantage of more context, and the GTK+ GUI has a button to invoke the upgrade logic, but I haven't plumbed anything comparable into the curses frontend. > So, what's up with this...? I'd need a trace of its behavior to say. Run with --log-resolver and --log-file=aptitude.log. (unfortunately the log file is larger than it needs to be -- I should probably trim out some of the setup logging by default) > Note that the above example, while demonstrative, is certainly not the > worst that's happened recently; sometimes it recommends (i.e., defaults) > deleting a bunch of fairly important packages because some random > i-don't-care-package has a conflict. aptitude itself will probably never distinguish between important and do-not-care packages (at least not in the sense of optimizing to avoid one or the other situation). However, its resolver hints could be used to tweak the score and/or tier of one or more packages to avoid this. Particularly once I finish the current round of changes, it'll be entirely conceivable that someone (such as the release team) could publish an apt.conf.d snippet containing hints to guide a particular upgrade. Daniel _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
