[Aptitude-devel] external solver support?

[Daniel Burrows]

On Tue, Sep 09, 2008 at 02:01:52PM +0200, Stefano Zacchiroli <zack at debian.org> was heard to say:
> On Fri, Sep 05, 2008 at 08:15:48PM -0700, Daniel Burrows wrote:
> >   I just wanted to post what my general plans are for the aptitude 0.5.0
> 
> Hi Daniel,
>   many thanks for this mail, it was a worth read not only for Arthur
> after all ;)
> 
> >     * Dependency resolver.
> 
> I feel the need to hack into this. A while ago, even though in private
> mail, we start discussing about the possibility of an ABI to interact
> with solvers external to aptitude. The goal is on one hand to support
> external solvers as plug-ins to be able to easy experiment with new
> solving algorithms without messing up with aptitude itself.

  I've heard some stuff about this from Michael.  I'm not sure what the
motivation is for creating a plug-in architecture rather than just
working on apt directly.  It seems like a way to complicate the problem
and introduce a lot of fragility in a fairly central piece of system
code.  On the other hand, apt is a fairly scary codebase to work with,
which is one of the reasons aptitude has grown a lot of stuff that
really ought to be in apt (and I suspect the same is true for pbuilder
et al).  But I don't see why any new resolver code has to be scary;
you could write it more cleanly than the rest of the apt code.

  I also don't think a plugin architecture will help with what I
consider the main difficulty with resolver algorithms, namely improving
their UI.  In order to improve the UI by introducing new algorithmic
capabilities, you have to change the interface between the resolver and
the main program.  For instance, the aptitude algorithm lets the user
see solutions beyond the first one the algorithm produces, and ask for
only solutions that don't remove a particular package -- two new UI
capabilities that you can't get with the vanilla apt resolver.  In
order to actually use those, though, you have to change the resolver
interface.  You could try to do an end-run around this by using some
sort of "extensible" interface (e.g., setting properties using strings),
but this just moves the problem around; you still have to actually use
those strings in the client code.

> On the other hand we already have (too) many package dependency solvers
> in Debian (apt, aptitude, pbuilder, ...) and it would be wonderful to
> factorize them out of the package manager codebase. I've already
> discussed with the APT developers about this and they are interested as
> well.

  Why should they be factored out of the package manager codebase?
Dependency resolution is a core package management function; they belong
in apt!  The only reason they aren't there is because no-one has done
the work to move them there.  Well, for me it's also nice to have the
code in my codebase so that I can fix problems immediately without
breaking other projects. :-)

> Even though we are at 0 with the design of the interface, I'm wondering
> whether you are interested in adding this as a perspective feature for
> aptitude 0.6.0.

  Mostly I'm focused on UI issues in this cycle, but if someone
contributed code I would be happy to incorporate it.

> That said ... it's time to start discussing the possible interface :)
> Even though the ABI, in my mind, is meant to be common across package
> managers, AFAICT aptitude will be the package manager with the most
> complex requirement to address, so it is probably worth to start the
> discussion here and then see how to converge to simpler package
> managers.

  Since I don't really know what you're trying to do with this plugin
system, it'll be hard for me to make a sensible suggestion.  But you can
find a lot of the interface between the main aptitude program and the
resolver in the aptitude source tree, under
src/generic/apt/resolver_manager.h and src/generic/problemresolver/solution.h.
Basically, aptitude needs a way of representing solutions, a way of
starting the resolver, a way of asking for the next solution, and
functions corresponding to the legal interactions between the user and
the resolver.

  Daniel