On Tue, Dec 08, 2009 at 02:48:47PM +0100, Julian Andres Klode wrote:
> > - 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 recommend as simple text message response encoded in the preamble
> I suggest a response consisting of a preamble with an additional
> property describing the cause of the error.
In fact, it would be a bit more complex than that. Or, better, we can
start like that, but then we will need some more structured information
(in particular for the interactive part). In particular, when a request
is not addressable, we will at list need to distinguish among the
following cases (there might be more):
- a package is missing
- a conflict among n packages is in place
Anyhow, let's say we start with something like the following, which is
returned by the package in case of errors:
error:
message: some explanatory text
possibly continuing there
That way we preserve the structure of 822-like format and we can add
more structured information later on.
Note that CUDF strings at the moment do not contain newlines (line
continuation are joined together suppressing newlines and leading white
spaces). So to structure message we would need some different kind of
convention.
> > - 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.
> It might look cleaner, but obviously requires more data. It also does
> not really match my plans which are based on changes instead of target
> state (as partially described in [🔎] 20091207172049.GA26830@debian.org).
I agree it will require more data and I was aware of your plans: still
what I posted is what I had ready and then I posted it nevertheless :-)
Let's try to look at the actual merits.
The required data are anyhow comparable in size to the data sent as
solver input, whether it will be a bottleneck or not is something which
we don't know yet. If it turns out to be very cheap, it might be an
useless optimization.
Also, regarding the matching with your plans, AFAIU APT2 will anyhow
play man-in-the-middle between the solver and the low-level package
manager. Are you trying to use an isomorphic format so that you can
simply pipe solver output to low-level package manager?
Final note (that partly explain my proposal): for most solving
techniques, the output I proposed is closer to what they internally
have. Having a diff there would mean that they (or an intermediate
pipeline component) have to compute the "diff" to generate the output
you want. The question is then who should better compute the "diff": the
solver or the package manager?
Anyhow, I don't have a strong opinion on this, I'd be fine with a diff
too, I'd just like to reach an agreement among involved parties. Can you
please suggest a 822-based diff format more or less in line with the
syntax I've shown?
> I am missing multi-arch support, which is important for the future. I
> don't really know about the status of the multiarch spec, but I would
> like to see it supported. A package stanza in the solver output would
> currently identify more than one exact package (it would identify the
> package with the given version on all architectures).
Unfortunately, I'm not familiar with the status of the multiarch spec
either. Can someone point us at which impact will multiarch have in
terms of dependency solving?
> Another thing is that there can be two packages with different
> dependencies, but the same name and version. I propose an optional id
> field which identifies an unique package. This field would be added to
> the input and the output (and it could be string, so we can pass
> hashsums).
Right, good point. This can be a bit tricky as currently the only (and
forcibly necessary) package identifier in CUDF model is <package,
version>. The id would not work though, consider the following example:
package: a
version: 1
depends: x
package: a
version: 1
depends: y
package: a
version: 2
depends: z
package: b
version: 1
depends: a
In expanding the dependencies of b, solvers will internally consider
them as something like "depends: a = 1 | a = 2", but here such a spec
would not be enough because which <a,1> is chosen makes a difference.
So, my actual solution is to use an id as you propose, but to mangle the
package name or the version with it, e.g.: a%id1, a%id2, ...
How often does that happen in practice?
How is it currently handled in apt and friends?
Thanks for your comments!
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