[Catalog-sig] PEP 345 Update

[P.J. Eby]

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.