On Dec 20, 2007 8:32 AM, Nagy Gabor <ngaba@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. Bye