[Catalog-sig] PEP 345 Update

[Tarek Ziadé]

On Mon, Aug 23, 2010 at 2:44 AM, P.J. Eby <pje at telecommunity.com> wrote:
...
>> 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."

-1, the PEP is about the metadata, not the softwares that will implement it.
IOW it's up to the tool (distutils, setuptools, etc..) to do the
proper UI for this.


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

A fork will use the Conflicts field, not the Obsoletes. If it uses the fork
it's a mistake to use Obsolete.

But if they trust this package, and install it, what's the difference at the end
since they will not use the other one ?

Could you give a a scenario where the end-user is duped ?
What is the harm that you are afraid of exactly ?

>  I also don't see how the field is beneficial (vs. conflicts).

The fields descriptions are quite clear, Obsoletes is useful for reorganizing
softwares into different releases names, whereas Conflicts marks a release
to be incompatible with another one,


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

Again the problems you are mentioning are to be taken care of at the installers
level and also at PyPI level. The metadata are just information about
the package,
and an installer can implement a paranoia level if it wants.

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

The PEP is not trying to address your trusts issues. When there's a
illegitimate
package at PyPI, people can complain on the Catalog-SIG mailing list.


Frankly, I don't really understand why you are concerned with this trust issues,
a end-user that installs a software is already trusting it, since it
installs it...

If you don't trust a project, and in particular what it claims in its
Obsoletes or
Conflict fields, just don't install it, and you'll be fine.


Tarek