[Aptitude-devel] external solver support?

[Stefano Zacchiroli]

On Tue, Sep 09, 2008 at 07:10:14PM -0700, Daniel Burrows wrote:
>   I've heard some stuff about this from Michael.

Too bad, I thought I've mentioned it directly with you: time to catch
up.

> 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.

The original motivation was specific of the Mancoosi project [1]. As we
are going to test several different solving algorithms, we would like to
have a way to test them without affecting directly the package manager
code base. Of course we don't want to forcibly push our changes to the
package managers for that reason, but since when I discussed with
Michael he was excited by the idea, I thought about pushing it forward
to other package managers as well.

  [1] http://www.mancoosi.org

Most of your objections seems to come from the assumption of "one true
solver" and I understand that, but at least in the interim we will play
with several solvers (to find the "good" one, if exists) and in that
scenario a plugin architecture is more appropriate.

> 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).

Yep, this is probably the reason why a lot of more advanced solving
logics have been implemented during years elsewhere than in apt. Still,
about your claim that the solver of aptitude should be in apt I'm
missing something: what about the interactive part? Would you be OK with
an API to interact with apt that let you interactively pause/restart the
solver when needed? It is a bit obscure how can you get rid of that
solver logics from aptitude otherwise ...

>   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

Yes, UI is a problem, and of course the problem is whether or not there
is an API which will make happy everybody. My idea is to start drafting
one that will satisfy aptitude needs and see how flexible we can get it.

> 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.

Indeed.

>   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. :-)

:-) Yes, you're right, maybe I was just tyring to fix the problem in the
wrong place, but still different tools have access to different
information to choose the right solution (think about aptitude garbage
collection of packages, before it was available in apt) and I think they
are right in doing so.

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

OK, very nice to read!

>   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.

OK, thanks for the pointer, I'd start from there and let you hear back
from me.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20080911/917da3d8/attachment.pgp