[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC interaction with external dependency solver: Debian-CUDF



Am Dienstag, den 08.12.2009, 12:04 +0100 schrieb Stefano Zacchiroli:
> 
> - 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.

> 
> - 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).

> 
> Comments on any of the above will be much appreciated!
> Cheers.
> 
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).

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).

Both also apply to CUDF itself, as far as I can tell.


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



Reply to: