[Catalog-sig] PEP 345 Update

[P.J. Eby]

At 02:48 AM 8/14/2010 +0200, Tarek Ziadé wrote:
>2010/8/14 Alexis Métaireau <ametaireau at gmail.com>:
> >  Hi P.J,
> >
> > Le 08/13/2010 10:20 PM, P.J. Eby a écrit :
> >> Has anybody given any thought to actually managing the *uses* of
> >> Obsoletes-Release and Conflict-Release?
> >>
> >> In particular, I'm wondering what installation tools are expected to
> >> do with this information.  Unless these fields are merely advisory in
> >> nature, I can foresee some user-hostile applications of the fields,
> >> e.g. by two forks of a package constantly marking each others'
> >> packages as obsoleted, conflicting, etc.
> > That's true, but if we choose to put our confiance in the packagers,
> > then we couldnt do anything to avoid them doing things like that. Others
> > packaging solutions have choosed to rely on trusted packagers only, and
> > have a specific processus to handle the packaging.
> >
> > I hope this not needed for python, if we were having such issues, we
> > could think of a solution at this time, I guess.
>
>You mean a package audit done by a human before it's added at PyPI ?
>
>PyPI is not a distribution, its a repository of packages for the community,
>so that will never happen.
>
>If you want to give your trust to just one single party, you need to
>use a Python
>distribution where each package is carefully audited and added, as you said.

That's actually my point about the obsoletes & conflicts fields.  In 
the kinds of system where that information typically exists, the 
installation tools trust the package info, because the package info 
comes from a trusted source.

This is information being put on PyPI, so it's not really sensible 
for tools to perform destructive actions based on the information.

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.

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.