Re: RFC interaction with external dependency solver: Debian-CUDF
Am Dienstag, den 08.12.2009, 15:03 +0100 schrieb David Kalnischkies:
> Hi Stefano & deity@,
>
> 2009/12/8 Stefano Zacchiroli <zack@debian.org>:
> > [ Explicit Cc to the people which expressed interest in this topic.
> > R-T/M-F-T set to deity@l.d.o as the most appropriate forum where to
> > discuss this. Let me know if I should keep the CC. ]
> I guess the three are subscribed to deity as this is the official
> dependency hell here where we search for the deity of dep-resolving. ;)
>
> > I'm finally ready to propose a basic format and protocol for interaction
> > between package managers and (external) dependency solvers. The format
> > is called "Debian-CUDF" [4] and can describe solver input and
> > output. The protocol, with a bit of fantasy, can be called "Debian-CUDF
> > protocol".
> A bit off:
> A while back i read something about the "mancoosi" project and (i guess)
> version 1 (The project seems to be now at v2). In this "old" version two
> different formats where proposed DUDF and CUDF. Am i right that
> "Debian-CUDF" is more or less the debian implementation of DUDF?
>
> > The idea is that package managers, as soon as they face a dependency
> > solving problem, will spawn an external process which reads from stdin a
> > Debian-CUDF document and return on stdout a proposed solution describing
> > the new set of installed packages.
> So everything the Packagemanager has to do is asking the user for his
> wishes, generate a Debian-CUDF, let the resolver do his job,
> understand his solution and apply it, right?
>
> The problem is therefore reduced to choosing the right sources for inclusion,
> but is this not already a problem the resolver should take care of?
> I mean, the CUDF specification seems to not include a way to say:
> "Heh resolver, you can choose between 2 different versions while resolving,
> but (if possible) please prefer this version over the other."
> (basically what we love and hate here as apt_preferences or pinning in short)
> So a packagemanager would need to choose wisely which versions he should
> pass to the resolver.
> Example: A user who explicitly say he want to install package A from
> unstable should have the right to say also "resolve dependency B at all
> costs, but if possible, choose the version from stable." Without resolving
> on it's own a packagemanager can't say if he should include now the stable
> version of B or the unstable version of B or both in the (Debian-)CUDF.
> (imagine A would be satisfied by both, but a new Version of C requires
> a specific.)
>
> I can think of a few more ways to influence the resolver (e.g. prefer hold
> over remove) which would be great to be included in a "standard" as the
> whole concept of exchangeable resolvers suffers if i need to pass different
> options to different resolvers to get the "same" result. Note to forget the
> difference between people who want to install recommends/suggests or not.
> (sry if this was what Stefano means with "Interactive solving" further
> down in his mail).
I guess that's what MooML is for:
http://www.mancoosi.org/papers/iwoce-2009-prefs.pdf
The creation of MooML is easy I think, but writing solvers supporting it
could be hard.
Interactive resolving means proposing the user a solution and the user
can accept it or request a new one (similar to aptitude); it could also
be enhanced to ask the user what he wants, e.g. "Do you want package A
or B?".
>
> > - Error reporting: currently there is no description about how the
> > solver reports error to the package manager (e.g. unsolvable
> > dependencies). It's rather easy to do, but requires consideration of
> > the possible cause of errors and how the package manager wants to
> > explain them to the user.
> I think we should agree over some sort of exit-status error reporting:
> The packagemanager than can display a common error message
> depending on the exit-status and optional display a free form description
> directly from the resolver what he provided instead of the solution.
I don't need differentiation between kinds of failures, my solver plans
have boolean return values.
>
> > - Solution description: the above returns solution in "here is the
> > new package status" style. Julian was instead proposing something like
> > "here is a diff from the previous package status". Mine looks cleaner
> > to me, but obviously more bloated.
> I think ideally the resolver already knows what he has done to
> achieve the "new" state (at least if he is not as greedy as APT ;) ),
> therefore it should be easier for him to provide a status diff than
> for the packagemanager to generate the diff and apply the diff.
Exactly, especially since package managers normally work on a concept of
changesets; except for APT which has a more or less global
change-the-state-to-what-you-want system.
>
> > Comments on any of the above will be much appreciated!
> I think Debian-CUDF should include an Architecture flag for Multi-Arch.
> I am pretty sure Multi-Arch can be modeled in pure CUDF without
> such a field but i think this will include quite a few conflict/break
> dependencies and maybe a package rename to pkg-arch and we
> already agree here over a simplification...
As I wrote. But we also have to take into account that according to the
multi-arch spec, only certain packages support it.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: