No, that's not the way it works. A conflict is always symmetric, no matter who declares it.

The beneficiary of these notifications is the aggregator attempting to build a systematically coherent system, rather than one with latent incompatibilities waiting to bite them at run time. It doesn't *matter* if "A conflicts with B" or "B conflicts with A", you cannot have a system with both of them installed that will be supported by the developers of both A *and* B.

Now, this beneficiary *may* be the packagers for a Linux distribution, but it may also be a larger Python distribution (ActiveState, EPD, etc), a web application developer, a desktop application developer, a system integrator for a large-scale distributed system, or anyone else that combines and deploys an integrated set of packages (even those a developer installs on their personal workstation).

It's up to the user to decide who they want to believe. Now, it may be that, for a given use case, the end user doesn't actually care about the potential conflict (e.g. they've done their own research and determined that the conflicting behaviour doesn't affect their system) - that's then a design decision in the installation tools as to whether or not they want to make it easy for users to override the metadata. In the Linux distro case, the installer *and* most of the metadata are largely provided by the same people, so yum/rpm/etc generally *don't* make it easy to install conflicting packages. Python installers are in a different situation though, so forced installs are likely to be an expected feature (in fact, I expect the more likely outcome given the status quo is that the default behaviour will be a warning at installation time with an option to request enforcement of "no conflicts").

Building integrated systems *is hard*. Pretending projects can't conflict just because they're both written in Python isn't sensible, and neither is it sensible to avoid warning users about the the potential for latent defects when particular packages are used in combination.

Cheers,
Nick.