[Catalog-sig] PEP 345 Update

[P.J. Eby]

At 01:36 AM 8/23/2010 +0200, Alexis Métaireau wrote:
>Le 08/14/2010 06:25 AM, P.J. Eby a écrit :
>>Granted, that fork isn't using PEP 345 to do its dirty work, but if 
>>the mechanism already existed in the field, there would've been no 
>>reason to whip up their own version of it.  And, more immediately 
>>relevant to the PEP, is that if there's an easy way for *anybody* 
>>to do it, it's likely that there'd be more occurrences of it.
>The only solution I see to this kind of issues is to review the 
>releases manually, and I'm not in favor of this.

Actually, all I'm suggesting is that the PEP recommend that 
installation tools should not take destructive action (e.g. 
uninstalling a previously-installed package) on the basis of these 
fields without user consent, and that they should allow users to make 
their own decisions regarding such things, even if it's in the form, 
"I'm not going to do this unless you specify an extra option to say 
you really mean to do it."

In particular, I'm especially wary of hostile use of "Obsoletes"; it 
seems especially likely to be used by forks to claim that one fork 
"obsoletes" the other, when in fact the situation is likely to be 
more complex.  I also don't see how the field is beneficial (vs. conflicts).

So, IMO, get rid of "Obsoletes", or in the alternative warn in the 
PEP that this may be used in a hostile manner and should not be 
treated as "trusted" information by an installation tool; that indeed 
it should only be considered as meaningful as a spam advertisement 
unless the verified PyPI owner of the obsoleted project is the one 
whose project is doing the obsoleting.

(Truth be told, though, I do not see what beneficial use case 
Obsoletes can have in the absence of a trusted distribution 
maintainer, or a same-author scenario.)