[Aptitude-devel] sigh, bad old upgrade behavior?

[Daniel Burrows]

On Tue, Feb 09, 2010 at 09:16:06AM +0900, Miles Bader <miles at gnu.org> 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