On Tue, May 18, 2010 at 12:22:18PM +0200, David Kalnischkies wrote:
> so the basic concept is:
> package manager -> debian-to-cudf-converter -> external solver
> -> package manager ?
Well, for the point of view of the package manager it can be seen as
simpler than that:
package manager -> external solver -> package manager
The proposed API of the first arrow is cmdline based (as I attempted to
describe in my former post), the proposed API of the second arrow is
stdout based with the format we agreed upon earlier on.
Then, in early deployment, it is possible that "external solver" gets
expanded to two different blocks where the first converts to CUDF and
the second does the actual solving. What I find nicer of this new
proposal is that the package manager doesn't need to care about that
architecture detail.
> How about a system more like
> package manager -> debian-to-cudf-converter -> package manager
> -> external resolver -> package manager ?
>
> What could be done then is that the package manager can attach
> an id to the stanza (lets say the converter includes the file it comes
> from and a count [as multiple versions can be included in one file] and
> the manager uses that to map this to his structure(s) with an id and
> pass it on with the request to the resolver).
Uhm, I'm not sure I understand the use case, but beside that (or maybe
_because_ of that, arguably) I fail to see why you can't have the same
with the proposed architecture. In fact, the "extra:" prefix can be used
to attach any kind of arbitrary field to packages, including the IDs you
mention.
I imagine you can see as annoying having to such IDs to file; if this is
the case we can setup a file descriptor based interface among the
package manager and the external solver and then allow the various
cmdline prefixes to match file descriptors. (That would also make the
interface way more flexible, FWIW.)
> After the id he can also attach other funky stuff he might want to pass
> to the resolver - e.g. that he already has this version downloaded -
> which would be hard to express to the converter by creating an extra-file.
> The converter therefore does the hard general stuff (version mangling,
> dependency rewriting, possibly make the info optional more anonymous
> [for a bugreport], …) and the manager just adds his own juice (if he want).
Indeed, that was exactly the purpose of "extra:". Unless I'm missing why
it should happen in two phases, I'd say that we can have all you want
using "extra:" during the first invocation.
> So the extended_states file is one of those? I ask as the stanzas in
> this file are for the package (of a specific arch) as a whole and not for
> a specific version.
Yes, I've identified that as a problem looking, e.g., at
/var/lib/aptitude/pkgstates. An interface which associates fields
directly to uniquely determined packages seems better to me.
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