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. 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. _______________________________________________ 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