This pull request passes (merged e130386 into a06ebdd).

Isn't that what we have conflicts for? On the other hand this is probably faster than solving conflict rules.

It is synonym for conflicts. But from repository side it is easier to add '<>' constraint to 'require' section, than build 'conflicts' section.

I don't see where you handle such rules in the solver

Do we really want to support <> and !=? I would only support the latter, because I don't think everyone knows <>, and having two operators that do the same is not especially useful.

@stof conflict rules are created from package links in the RuleSetGenerator. However this here would only change which packages are returned by whatProvides in the Pool, which should be better performance wise.

As for the operator I don't really mind either way. But I guess it'd be cleaner to have just one operator. At the same time someone trying to use <> might be confused why it doesn't work.

@naderman does the pool already support this operator without any change ?

Oh I thought that was in this PR, but it is not, you're right.

The code to handle !=/<> would need to be added to src/Composer/Package/LinkConstraint/VersionConstraint.php

It uses version constraint which supports both operators so I guess it's
fine as is.

If you look at its code, I don't think it correctly does.

Err I meant to say the VersionConstraint class uses version_compare, which handles != and <>. Damn heat :)

Well it doesn't just use version compare, as it compares ranges of versions with each other, so the code needs to be extended to handle != and <> correctly.

This pull request fails (merged c6bafe04 into a06ebdd).

Check tests please. I hope I did right assumption about matching behavior.

Matching behaviour looks correct to me.

This pull request passes (merged 9f08764 into a06ebdd).

Merged, thanks!