[Catalog-sig] PEP 345 Update

[P.J. Eby]

At 09:29 PM 8/13/2010 +0200, Alexis Métaireau wrote:
>Hello all,
>
>As we previously discussed here, I've updated the PEP 345 to refer 
>on project, releases and distributions when needed, instead of 
>distributions all the time.
>
>What I've done is:
>* added a glossary on the top of the document,
>* updated the *-Dist fields to *-Release, as the informations they 
>provides are relative to releases, not distributions.
>* As Tarek suggested, added a Conflict-Release field, to deal with 
>conflicting releases.
>
>You could find the new version on bitbucket [0], and especially this 
>changeset [1], waiting for feedback.
>
>[0] 
><http://bitbucket.org/ametaireau/python-peps>http://bitbucket.org/ametaireau/python-peps
>[1] http://bitbucket.org/ametaireau/python-peps/changeset/3000402bda90

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.

I'm also confused a bit by the version specifiers language regarding 
pre/post releases.  Examples of how  to specify ranges involving them 
would be helpful.

Next, does Requires-External support environment markers or not?  The 
section on environment markers says yes, but the section on 
Requires-External appears to say no (it says name optionally followed 
by version).

Last, but not least, is there a reason we're avoiding specification 
of Supported-Platform?  For at least Windows and OS X, we have (or 
can define) a reasonable set of platform strings.