[Aptitude-devel] Recent aptitude commits

[Daniel Burrows]

On Wed, May 06, 2009 at 07:50:07PM -0700, Daniel Burrows <dburrows at debian.org> was heard to say:
> On Tue, May 05, 2009 at 08:01:40PM +0200, Obey Arthur Liu <arthur at milliways.fr> was heard to say:
> > This would also be a first step toward converging the preview tab and
> > resolver tab, which IMHO should be merged to simplify the interface in
> > the user's mental representation. (of course, language about conflicts
> > would be reduced if there aren't any so as to stay simple)
> 
>   I think it would be dangerous to fully converge those two.
> 
>   The preview tab lets the user change which packages are going to be
> installed, upgraded, what-have-you.
> 
>   The resolver tab lets the user see the changes proposed by the
> resolver and ask it for more proposals.
> 
>   You can't manually change the states of packages without screwing up
> the resolver and making all the solutions you've already found invalid,
> and I don't know any system that would change that.  Putting these
> functions in the same tab would basically mean you had two totally
> different pieces of functionality that interfere with each other
> and are accessed via the same interface.

  So, I'm currently wrestling with how to reconcile my incremental
resolver changes with the ability of the user to post and retract
constraints, without making things too inefficient.  It's looking more
and more like I'm going to end up with a system for tracking inference
trees and retracting information when it's no longer relevant.  Right
now the only thing that can be pulled out is statements that "this is
deferred" (and "pulling it out" means removing it from the deferred set
and sticking it back on the open queue).  However, this machinery will
get us a lot of the way towards being able to retract steps when package
states change.

  What that means is: after I'm done, the resolver will be within sight
of a design where we could stop blowing it up every time a package's
state changes, and instead just back out and discard the search branches
that are invalidated.  In that scenario, it might be entirely feasible
to do what you suggested above, although I'll have to think a little
more about it once I'm done with what I'm working on right now.

  Daniel