Arch Linux

Well, that's interesting, it shows that it's possible to have two conflicting packages installed,
so that probably justifies adding that conflict check to testdb.

However, that pactest is very ugly, as you said yourself. It's not easy to follow, and it looks very far from a real case,
so I'm not sure what should be done with it.

"I'm not sure what should be done with it."
Well, this bug will disappear automatically when we finally rework conflict resolving.

And I disagree here: I am stricter. This is a bug. I don't like "this works in most cases" reasoning; pacman simply shouldn't allow install 2 conflicting packages.

And since we already have a sync.c-rework patch, I don't understand why we want to keep this bug.

Yes, this is a bug and should be fixed.
What I meant is that we already have a ton of pactests failing, and no fix for them.
So we should concentrate on the more important and realistic cases first.
And secondly, since this is an unrealistic case, it's not critical for 3.1, it can be fixed later.

I agree with Xavier here. It's always nice when people focus on _fixing_ bugs instead of inventing new ones.

Stricter though it may be, this is software, and software is about the "common case".

This is a ridiculous edge case and effort will be better spent elsewhere. Like... fixing things.

"It's always nice when people focus on _fixing_ bugs instead of inventing new ones."
The patch I sent in August, fixes this too.

To be more concrete: http://www.archlinux.org/pipermail/pacman-dev/2007-August/009078.html
This was adopted by Xavier in his sync branch.

This fixes all of conflict resolving problems around here, including  FS#9024 ,  FS#8897 .

I just made a more conservative version of that resolve conflict cleanup patch.
I mostly changed the target vs target part, and the result is that it breaks only two very weird pactests, that Dan wanted to change anyway.
And yes, it should fix these three bugs indeed.

Well that's totally different, and thanks for the patch - I just saw no where in the bug report at all that this bug was fixed by a patch you submitted. That's important information.

I added a check to make pacman fail in the case of a conflict between two explicit targets, because that makes more sense.
Attaching the new patch.

Xavier, I like these patches.

Well, I find the first version cleaner.
I don't understand why we handle explicit<->explicit target conflicts only (exit with failure). What if a pulled dependency kicks out an explicit package (pacman -S nvidia libgl)? So either we should also "disable" this case or allow the first one too.
As I said already, I would be happy with the first version of your patch: with a warning added, if package is removed from the target list (-S always needs confirmation before commit, so user can decide whether to continue or not) <- contra: this may confuse some users (see the '-S xorg nvidia' for example).

Some minor comments about target resolving policy:
1. There is an edge case, when this leads to an asymmetry (not important but I mention it):
a<->b<->c (<-> stands for 'conflicts with') and a<->b can't be autoresolved but b<->c can be autoresolved by removing package b from the target list. Pacman will fail if he find a<->b conflict first, and resolve if he find b<->c conflict first (this depends on package order in the target list).
2. This is just a note:
Like in '-S xorg nvidia' example, if we have to choose between two conflicting dependencies, we choose the one which was added later to the target list (which means that the other conflicting dependency [which was already in the list!] didn't a satisfy a needed dependency, but the new added package did) almost always. This is the analogue of how target<->localpkg conflict resolving works.

"I don't understand why we handle explicit<->explicit target conflicts only (exit with failure). What if a pulled dependency kicks out an explicit package (pacman -S nvidia libgl)?"

There is a big difference. In the first case, what the user asked is clearly not possible. The targets that were explicitly requested by the user can't be installed together.
In the second case, there isn't a direct conflict. The conflict is caused when resolving dependencies, which is done by pacman. So it can be up to pacman to fix this problem. Besides, the pulled dependency kicks out an explicit package for satisfying another explicit package. And finally, it only kicks out an explicit package for replacing it by a provider. In your example, the user asked libgl, but he will get nvidia-utils, which is a provider of libgl. So that should still be alright.

I don't really understand this.
First of all, I don't see any difference between "-S libgl nvidia-utils" and "-S libgl nvidia": installing explicit libgl is not possible. In both cases libgl will be installed as a provision (due to our conflict resolving policy).

So I interpret your second version:

1. explicit<->explicit: we inform the user, that he wanted to install two conflicting literal(?) package, and don't allow this.
2. explicit<->pulled: we silently kick out the explicit package behind the user.

I think, that the main purpose should be here to inform the user about the fact that pacman cannot/won't do exactly the requested operation (installing literals): either by not permitting the requested operation or giving a warning.

PS: After your pending  FS#8723  we can assume that user wants to install literal.

typo:  FS#8763  patch

Oh well, I don't know finally. I mostly made this change because Dan thought the rules of sync898 pactest should be changed.
Personally, I don't even know which version I prefer. If you prefer the old one, I'll just keep both on my git tree.

"If you prefer the old one, I'll just keep both on my git tree."

Thanks. I prefer the old one with PM_LOG_WARNING in case of explicitpkg removal (this is just a s/DEBUG/WARNING/ in your patch). And I can also accept the "forbidden explicitpkg removal" if that is implemented consistently (for both explicit<->explicit and explicit<->pulled case).

Anyway, this is just a minor "issue", of course even your 2nd version in much-much better then the current conflict resolving monster ;-) Thx for your work.

So, would the attached patch applied to my first version make you happier ?

Yes. What's more, it is better than my always-warning solution, but imho the pkgcache check is not needed. (The fact that new package conflicts doesn't mean that the old one also conflicts: provisions, versioned conflicts etc. And imho there is nothing wrong with displaying both ~"Warning: foo removed from the target list" and ~"Do you want to remove foo? [Y/n]" messages.)

You're right again.
Hopefully it's right this time.

This looks OK to me.