On Mon, Sep 17, 2007 at 01:26:55PM +0200, Nagy Gabor wrote:
OMG, I noticed that current pacman won't resolve target<->target conflict (it stops with unresolveable conflict error <- so that ~150 line conflict-resolution monster is not so efficient in sync.c ;-). However pacman may still remove packages from the target list: sync.c: /* pacman -S blackbox xfree86 ... */.
Actually, I think that's the only reason why your patch breaks a few pactest. In case of target <-> target conflicts, pacman used to fail. But after your patch, it tries to automatically resolve it by selecting one of the target. You said that yourself :) Oh, I remember now, but I thought that those pactests "decide" not to resolve that conflict [Note: I used the word 'autoresolves' here: http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html];-) And I never could get myself to read that whole messy part in sync.c, however I saw that pacman _can_ remove packages from the target list.
So you broke the pactests that had a target <-> target conflict, and expected pacman to fail. I am still not sure what's the best default behavior (for example, the behavior using --noconfirm, which is how pactest are run). But in any cases, it's probably better to ask the user (you already said that as well).
I don't understand that part at all: resolvedeps first search for (blackbox's) dependency satisfiers in the target list. So it will find xfree86, if that dep is OK [in this case we don't need to remove anything]; if xfree86 dep is not OK, resolvedeps must find and pull a real satisfier (xorg), [in this case we cannot remove xorg, because we will get a broken dep]. Any idea?
See : http://www.archlinux.org/pipermail/pacman-dev/2007-July/009041.html http://www.archlinux.org/pipermail/pacman-dev/2007-August/009155.html
I would be happy if only the comment would be outdated ;-) Hopefully the whole part around that comment never runs (otherwise it breaks some depends), so it can be removed [line 504-554, 577-587(?)]. So the current sync.c is not so dangerous as I thought, however that is very ugly (IMHO): [asked variable is unneeded, sync1003.py still fails] Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/