On 2012-12-08 20:18, PJ Eby wrote:
On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby <p...@telecommunity.com> wrote:
So if package A includes a "Conflicts: B" declaration, I recommend the
following:
* An attempt to install A with B already present refuses to install A
without a warning and confirmation
* An attempt to install B informs the user of the conflict, and
optionally offers to uninstall A
In this way, any collateral damage to B is avoided, while still making
the intended "lack of support" declaration clear.
How does that sound?
No, that's not the way it works. A conflict is always symmetric, no matter
who declares it.
But that *precisely contradicts* what you said in your previous email:
It's to allow a project to say
*they don't support* installing in parallel with another package.
Just because A doesn't support being installed next to B, doesn't mean
B doesn't support being installed next to A. B might work just fine
with A installed, and even be explicitly supported by the author of B.
Why should the author of A get to decide what happens to B? Just
because I trust A about A, doesn't mean I should have to trust them
about B.
[snip]
If package A says that it conflicts with package B, it may or may not
be symmetrical, because it's possible that package B has been updated
since the author of package A discovered the conflict, so it's
important that the user is told which package is complaining about the
conflict, the one that is being installed or the one that is already
installed.
It may also be helpful if the package that includes the "Conflicts"
declaration specifies which version of the other package it was last
tested against in case there is a more recent version of the other
package that does not cause the conflict, or, indeed, that there's a
more recent version of the package that includes the "Conflicts"
declaration that does not cause the conflict.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
