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