[pacman-dev] abs split from pacman before release

Nagy Gabor ngaba at bibl.u-szeged.hu
Thu Dec 20 13:10:59 EST 2007

> On Dec 20, 2007 8:32 AM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > resolving is just ugly. These are not critical problems at all, but
> > IMHO the current state of resolving code is almost critical, and I'm
> Could you define "almost critical" for me? See, I look at this stuff
> and say "man, that sure does suck, but it works for the most part". I
> think you see it a different way, so could you help me understand why
> you feel this is "almost critical"?

I said "almost critical", because it is really hard to follow what is
happening there (or maybe I'm just too stupid to clearly understand
that), and I think "black boxes" in our code are dangerous and unwanted
(anyway, that codepart is needlessly long).

I show you an example:
Every local package is listed in at most one target package's replaces
list => you cannot remove target package after targetpkg<->localdb
conflict resolving, because 'lpkg' localpkg can conflict with two
targets in the target list, and only one of them replaces lpkg, so if
we remove this replacer (in target<->target resolving) then the conflict
will appear again. Fortunately after Xavier's patch target<->target
conflicts are resolved first in conflict.c, so this is not a bug now
(but I cannot see any comments in the _alpm_sync_prepare, which
indicates that this behavior is assumed).

Imho the example above shows that it is not easy to follow what
happening when you remove a target from the target list (because of the
replacer list -- and at most one replacer for lpkg), for
example I could create the localdb breaker FS#8899 using this -- maybe
one can find/run into real-life examples too.

Summary: I cannot say signed-off for sync.c, but maybe others can.


More information about the pacman-dev mailing list