Re: RFC interaction with external dependency solver: Debian-CUDF
Am Dienstag, den 08.12.2009, 16:02 +0100 schrieb Stefano Zacchiroli:
> 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.
Like for debian/control, line with space and dot. We can use exactly the
same format as we use for package descriptions.
>
> > > - 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?
Now, but I create the new objects for each change, using a subset of the
attributes needed for the request.
>
> 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?
Creating the diff in the solver would be more efficient for some cases
where the solver somehow has a diff, but as efficient as computing the
diff in the package manager if the solver works with the state approach.
This means it is at least as efficient as computing it in 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?
Just return something similar to the request stanze or several stanzas
in the form:
package: name
version: version
action: <install/remove/upgrade..>
In this case, "action" would give the choice between values like
install, remove, upgrade (just like the enum I wrote in the other
message I refered to).
>
> > 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?
The thing is specified on https://wiki.ubuntu.com/MultiarchSpec, if you
want to have a look at it.
>
> > 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.
I just want to know the exact package afterwards, so I can download the
correct one. And with an ID, I would know which <a,1> to install.
>
> 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?
PackageKit uses this one:
http://www.packagekit.org/gtk-doc/concepts.html#introduction-ideas-packageid
, but I guess this is also to incomplete for those cases.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: