[Aptitude-devel] Design notes on producing better (or at least more predictable) resolver results.

[Daniel Burrows]

On Mon, Feb 16, 2009 at 08:03:24PM -0800, Daniel Burrows <dburrows at debian.org> was heard to say:
> On Sun, Feb 15, 2009 at 08:26:57PM -0800, Daniel Burrows <dburrows at debian.org> was heard to say:
> >       We would accomplish this using some sort of "link" that means
> >       "whenever you create a search node containing this version, also
> >       create a search node that adds this other version (if it's
> >       legal)".  So, we would add links from the removal version of
> >       "Old" to every version of "New" that fully replaces "Old"; if the
> >       resolver had a search node S that installed "SomethingElse" and
> >       it was planning to fix its conflict by removing "Old", it would
> >       generate the following successors:
> > 
> >           (a) S + "remove Old"
> >           (b) S + "remove Old" + "install New"
> > 
> >       The difference is that the current resolver will only produce (a)
> >       because it has no reason to try installing New.

  I've been looking into implementing this (with my later suggestion
about treating it like a soft dependency).  This has led to some second
thoughts.  If a package is obsoleted by another package, I think it's
clearly a feature if we spontaneously try installing that other package
when removing the first one.  But full replacement isn't just used for
obsolescence.  According to policy 7.6.2, it's used to determine "which
package should be removed in case of a conflict".  And the main example
that's given of full replacement is mail transport agents.

  If exim4 is removed for dependency reasons, should aptitude try
installing some random other MTA instead?  It seems wrong, and it's
also quite a corner case (as is the whole "full replacement" thing).
Maybe I should just punt for now and finish implementing tiers without
trying to make replacements happen at the lowest tier.

  Daniel