[ 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. ]
On Thu, Nov 05, 2009 at 01:19:21PM +0100, Michael Vogt wrote:
> On Thu, Nov 05, 2009 at 09:39:36AM +0100, Stefano Zacchiroli wrote:
> > On Wed, Nov 04, 2009 at 06:18:05PM +0100, Julian Andres Klode wrote:
> > > Resolving dependencies, etc.
> > > ----------------------------
> > > External dependency solvers will be supported. I had an e-mail
> > > conversation with zack on this topic, and he asked me whether this
> > > would be possible. I'm just waiting for his final proposal on this
> > > topic. This should probably be coordinated with cupt as well, so we can
> > > share external solvers. The exchange format could be CUDF[0].
> > I confirm that I'm active on this, we've mostly finished the spec for
> > CUDF. Once that is done (no more than a couple of weeks), I'll get back
> > to you with a format specification based on CUDF syntax (which is plain
> > text / RFC 822, don't worry about XML or similar stuff), but better
> > suited for Debian and with a connector to use it with any CUDF-based
> > solvers.
> I'm certainly interessted in this. Having support for external
> resolvers is something I would like to see in libapt as well.
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".
First some pointers and explanation.
CUDF itself [1] (which is not the same thing of "Debian-CUDF") is a
format to describe upgrade scenarios in a distro-independent way. As
such it takes care of complex stuff like the different dependency
semantics in dpkg vs RPM and version number normalization. The full
specification of CUDF is a rather lengthy PDF document [3] (not for the
faint of heart!), but there is now a very short primer available on the
web whose read I recommend to anyone interested in discussing this.
[1] http://www.mancoosi.org/cudf/
[2] http://www.mancoosi.org/cudf/primer/
[3] http://www.mancoosi.org/reports/tr3.pdf
Within Debian (and derivatives) we know that the low-level package
manager is dpkg, hence to reuse solvers within Debian we can use a
format which resembles more our package list syntax and semantics. Such
a format is Debian-CUDF [4].
[4] http://www.mancoosi.org/cudf/debian/
(assumes basic CUDF knowledge, I suggest reading [2] first)
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.
From here on, several aspects still need to be fleshed out, a few that
come to my mind:
- 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.
- Interactive solving: above I've implicitly assumed that solving is
always batch, which is not the case. I've a basic interaction protocol
that addresses this, but I would first like to agree on the batch case
as most of the above will be reused in the interactive case.
- Performances: I've the feeling that a big pipe of plain text can be a
bottleneck; we can image a binary equivalent, but first it'd be better
to have numbers about the actual impact of the pipe.
- Implementations status:
* Eugene used to have a preliminary implementation of this in CUPT,
then due to my delay it has not been maintained. Eugene: do you
think it would be easy to port the implementation to the above
format?
* Julian was waiting for me on a format proposal: here we go! :-)
- 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.
Comments on any of the above will be much appreciated!
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