[Catalog-sig] PEP 345 Update

[Alexis Métaireau]

 Le 08/14/2010 06:25 AM, P.J. Eby a écrit :
> The idea that this *wouldn't* be used in a hostile manner by a fork is
> also incorrect, since I know of at least one Python package on PyPI
> today that not only kicks out its competition, but actively prevents
> it from being reinstalled as well.
I think this is out of the scope of the discussion, here.

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

The "conflict" and "obsoletes" fields allows such usecases, you're
right; BTW, I cant see any problem about this. That's the end user which
choose what to install. The system in place in PEP 345 only allows to
say: "Those two arent compatible", or "This is the new version of this
old tool".

In some cases, that's true, technically, to say that the way tools are
implemented makes the two impossible to install on the same environment.
That's the only thing that matters in the scope of this PEP, because we
*need* to have a way to know this.

Cheers,
Alexis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20100823/afbaaaab/attachment.html>