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.)
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
