On Fri, Dec 11, 2009 at 12:01:36PM +0100, David Kalnischkies wrote:
> It is just that i personally think more[1] resolvers will have an idea what
> they have changed (to undo their decisions) so for these it should be trivial
> to output diff-style. These which really don't know what they have done
> should be able to compute a diff rather trivial also. The same would be true
> for the new-style, but the packagemanager have to compute the diff at some
> point anyway, so we have in the changes-aware-resolvers a diff to new convert
> step which will be reverted by the packagemanager later on.
Fair enough, I agree with most of your arguments. So that's a one more
for the "diff style".
> I think we should really agree on one style and stick with it.
> We have two fronts:
> * Support both formats -> increase the complexity of the format
> and (maybe) of the resolvers
I fully agree, but I don't want to make things harder for Cupt, for the
simple reason that "competition" at this point is badly needed in the
package manager front, and Cupt seems to be a fairly widespread
competitor at the moment.
So, what I propose is to have the diff format by default and add a
format-request property (not needed by default) that will be used to
request a full state output. By the way, the initial request will need
to be changed slightly anyhow as I believe we should at least put there
a format version string.
> Given, that maybe in the future the counter of packagemanagers will
> stagnate so that we will (maybe) have in (a far away) future more
> resolvers than managers the second option is better in my eyes.
[ Pun-plug: well, I already have several solvers to offer, as soon as we
find a way to plug them in ;-) Believe me or not, but surprisingly
people from the academia are quite interested in facing "big"
resolution problems as those entailed by dependency resolutions in
distributions like Debian and Ubuntu. ]
> Uh, and btw it would be really cool if we would stick as close as
> possible to the original CUDF, so this is maybe a topic not only for
> Debian-CUDF.
That's a design principle of mine too. The changes that I made for
Debian-CUDF are just to avoid having to duplicate the same translation
logics (about virtual packages, about version strings vs numbers, ...)
in all Debian-based package managers.
Cheers.
> [1] Okay, this is properly a topic on its own and a bit complicated without
> an eightball to provide the actual truth, but i really think dependency
> resolving is not a true/false business which could be solved in 2-SAT,
> so you have to rate at some point your possibilities and if you want to be
> really good you will want to be able to revert this rating later on.
Yes, it's a topic on its own, but let me just give a stab on this. It is
true that you have to rate, but the problem is that constraints are very
very global and reverting changes can really mean having to do a lot of
changes performed thus far. Doing that naively (i.e. without exploiting
the knowledge of people which have been doing that for the past 20
years) will easily lead to unmanageable and/or incomplete algorithms.
> P.S.: Stefano, I prefer "good old APT", but i am maybe a bit biased. ;)
Yeah, I'm truly sorry, I meant that, in spite of the "plain old"
expression that I've actually written down :-(
--
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