The pending patch [1] from Nagy for conflicts handling broke the following pactests : sync040, sync041, sync990 These pactests are "target vs target" conflicts that pacman doesn't try to resolve, and just stops. Nagy's patch tried to resolve these conflicts by removing one of the two conflicting targets. So that broke the 3 pactests above. When trying to change the code slightly to make pacman fail in this target-target case, the 3 pactests above now succeed, but it breaks 5 others : sync893, sync897, sync898, sync992, sync999 These pactests are actually other kinds of target vs target conflicts. So finally, pacman tries to auto-resolve these conflicts more often than not, instead of just failing. That's what I failed to see earlier, that there were different cases to consider. Now I see at least 4 kinds of target-target conflicts. I'm attaching 4 pactests to illustrate that. In my opinion, pacman could always fail with these target-target conflicts. This kind of conlicts is very rare (it doesn't make any sense to install two conflicting targets). However it can happen in an odd situation (see bug 7415), where a group is splitted across several repos. But pacman's behavior in this case is very odd anyway.. So I think it wouldn't be worse if pacman just failed, and so it would be left to the user to fix it manually, by removing the conflicting package from the targets, for example using --ignore. So this would give both a more coherent behavior, and cleaner code. If that's alright, I will try to edit (correctly this time) Nagy's patch to behave like that. But the 5 pactests listed above will then have to be edited accordingly (mostly changing PACMAN_RETCODE from 0 to 1). [1] http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html