Well, I'm all for going the easy way 1. :) I think the old behavior is acceptable, and that we can keep it for now, and avoid breaking the few pactests that depend on it. Your patch just needs to be slightly edited for doing that, right? Right. You can simply replace the autoresolve stuff (around TODO) with an error message.
But I must mention that (hopefully) my patch cannot break anything in the local db, even if you let it remove one of the conflicting packages from target list (my TODO says: let user choose); because the final dependency check is done just before the commit. So if it could resolve the conflict, then everything is OK (no dep/conflict error; apart from some orphan dependency install :-(), and if the resolving breaks a dependency, pacman will stop with an error message (which is the default behaviour now in case of target<->target conflict; however, user may get some strange error message) So 2. is already done by patch: It is difficult only if you want to solve some really exotic cases (what I mentioned in 2.); pacman now stops with an error message if it is not smart enough to do that (however, the problem may solvable). Summary: with my patch pacman tries to resolve the target<->target conflicts and it may not be clever enough to do that correctly, then it stops. Bye, ngaba PS: As I wrote this e-mail, the "assymmetric" conflict storing came into my mind again: http://www.archlinux.org/pipermail/pacman-dev/2007-August/009091.html ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/