On Sat, Dec 8, 2012 at 5:06 AM, Nick Coghlan
On Sat, Dec 8, 2012 at 4:46 PM, PJ Eby
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. Look, I really don't care about the individual fields' definitions that much. I care about only one thing: A shouldn't get to (de facto) dictate what happens to B. If you *really* want the behavior to be symmetrical, then it should *only* be symmetrical if both A and B *agree* they are in conflict. (i.e., both refer to the other in their conflict fields). Otherwise, it should only be a warning. There are tons of other things that I could argue here about the positions you've laid out. But all I *really* care about is that we not define fields in such a way as to permit or encourage inter-package warfare -- intentional or not. Solutions acceptable to me include (in no particular order): * Make declarations affect only the declarer (as with Obsoleted-By) * Make declarations only warn users, not block installation or result in uninstallation * Have no automated action at all, and document them as intended for downstream repackagers only * Toss the field entirely * Make the field include a context (e.g. a distro name), so that only tools explicitly told you're operating in that context pay attention * Use the new metadata extension vocabularies to define hints for specific downstream packaging tools and systems * Replace "conflicts" with a specification of resources actually used by the project, so that such conflicts can be automatically detected without needing to target a specific project And there are probably others I haven't thought of yet. If you can be clearer about what it is you want from the Conflicts field *other* than just wanting it to stay as is (or perhaps *why* you would like to have the Python infrastructure side with project A over project B, irrespective of which project is A and which one is B), then perhaps I can come up with others.