On Tue, Dec 08, 2009 at 03:03:14PM +0100, David Kalnischkies wrote:
> > [ 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. ;)
OK, let's drop all Cc-s then :-)
> 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?
In principle yes, but the purposes are a bit different.
Short story: ignore DUDF, we won't use it here.
Long story: DUDF is meant to submit problem from user machines to a
central repository over the net (a la popcon). So, in that format, we do
support optimizations like sending a checksum of the APT package lists,
so that the receiver looks up the checksums in a historical database and
expand them. Here we don't care about this, because the solvers really
need full bloated data. Also, the DUDF format in fact is very
under-defined and does not have a clear semantics, it is just an XML
skeleton and not much more.
> 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?
Yes, written this way it looks easy :-), but the details are still
tricky (as I'm sure this thread will show :-)).
> 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?
Julian here is right that that role will be fulfilled by MooML (which we
don't have yet). Ideally, with CUDF you just express the user request
and the format semantics ensure you don't return unsound solutions
(i.e. solutions that violate dependency constraints).
Additionally (by using another property in the "request:" stanza I've
already shown) you can specify extra constraints (e.g. don't install
package maintained by "Foo Bar" because I don't trust him) or
optimization criteria (e.g. among all possible solutions, choose the one
which minimize the installed-size).
Pinning can be expressed in such a way.
You might be wonder that this divide and conquer approach is a bit too
complex, but in fact proper dependency solving is *terribly* complex and
I'm trying to address (from package manager engineering point of view)
one concern at a time. Still, we've already thought about these kind of
issues and we haven't simply ignored them. We believe they can be
plugged in one step at a time. The link about MooML given by Julian is a
good pointer to get the "big picture" all at once.
> 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.
With my proposal of returning an "error: " stanza, I believe that we can
consider that "ordinary" error scenarii will be handled irrespectively
of the exit code (or, if you want, by relying on always 0 exit code). If
we agree on that, all other exit codes are very exceptional situation
that can be described as "can't start the dependency solver".
> - 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
Exactly: the error response is in fact a complex object, so I believe we
should push most of its details in the return format rather than using a
plethora of different exit codes. YMMV.
> 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.
Well, a lot of solvers we can apply here have in fact a global vision of
all constraints and don't work by changing the current status, but
rather finding a satisfactory solution. That's why they are closer to
the "new state" approach than to the "diff" one, but that's not a big
deal: for such solvers we can compute the diff before sending it to APT
(or equivalent).
Anyone around which actually would prefer the "new status" approach? If
there isn't anyone, I guess the consensus is quite clear already :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature