Re: RFC interaction with external dependency solver: Debian-CUDF
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).
> - 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.
As far as i can imagine we have in theory:
- an unavailable package
- a dependency on a too high/low version (not available ?)
- a try to install two conflicting packages
and in practice a wild mixture of all these problems at once resulting in
the uninstallability of one or more packages, so optional we could also
agree over some sort of format to say the packagemanager which
package could not be installed. A why would be interesting but i
think it is in general to complex to be easily describable and
will not help many users anyway, so this could be included in the
free form.
> - 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.
> 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...
Best regards / Mit freundlichen Grüßen,
David "DonKult" Kalnischkies
Reply to: