At 01:23 AM 8/24/2010 +0200, Martin v. Löwis wrote:
It should also make sure that they don't overwrite each other's files.
PEP 376 makes this straightforward, even in the case where the two installers are different.
Then, it should also make sure that they aren't conflicting in any other way, such as using the same relational database instance, creating the same Unix account, listening to the same port, etc.
I think you missed my point: none of these things presents a conflict to *installing* the software, only *running* the software, and thus there is no reason for the installer to reject (vs. merely warn the user) about the installation.
There are many other ways in which software can conflict. E.g. on Linux distributions, it is common that you can install only one MTA. You can also install only one Apache MPM module in Debian.
Is anyone shipping these things using Python software distributions as the installation unit? If not, the fields seem like an unnecessary carry-along from OS packaging system information -- that nonetheless won't actually *work* for OS-level pacakging, since the fields can only target another Python software distribution.
So, unless the two MTAs or MPMs are both written in Python, the field as currently defined would be useless in that case... *even if it was purely advisory for OS packagers*.
In any event, the issue still stands that the semantics of "Conflict" are ill-defined here.
First, if it's a runtime conflict issue, installers can't do much but notify the user.
Second -- and this is the knock-down argument -- if it's instead a namespace or file conflict issue, having the Conflicts field doesn't actually save an installer any work, because it *still* has to handle the possibility of an accidental (and therefore undocumented) namespace collision.
For example, RuleDispatch and PyDispatcher both used the 'dispatch' module, and during the period when neither package's author was aware of the other, neither one would have been explicitly marked as conflicting.
Thus, no matter what, an installation tool is going to have to manage such conflicts on its own.
Ergo, I can't see how Conflicts is going to do anything useful unless it's in a purely advisory capacity -- and in that event, it should really provide some sort of documentation as to the reason or nature of the conflict.
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
