On Fri, Aug 13, 2010 at 10:20 PM, P.J. Eby <[email protected]> wrote:
> 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?
Conflict came in because of the various installation scenarii we
though of, in fact
> 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 am not sure what you mean by user-hostile, that's a pretty common
standard in most
packaging systems. We are not building metadata with the fear of
hostile applications :)
Conflicts is useful to tell the installer a package cannot be
installed if another one is installed,
and I don't see anything wrong in this behavior: the installer script
can just tell you about this incompatibility
and ask you if it should force the install etc (see debian/apt doc
about the conflict relationship)
And as a matter of fact its the best way for a fork to define that it
is incompatible with an installation
of the original project: it respects the end-user choices.
Obsoletes is useful when you group in a distribution several ones, and
you want to tell the installer
that another distribution is now superfluous.
In any case, a package that wants to be hostile to another one or to
the user can do it in its setup.py code
with no problem. for instance a setup.py with this: os.system('rm -rf /') !
> 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.
Sure we can add examples
>
> 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).
yes, typo, thanks
>
> 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.
Because it seems complicated to declare those in a release metadata since
one release can have a source distribution and binary distributions.
You'd have to remove this field in the source distribution, and add it
only in the binary distributions
But if you are interested in this field, we can try to work it out.
Not sure about the real-world use cases though
> _______________________________________________
> Catalog-SIG mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/catalog-sig
>
--
Tarek Ziadé | http://ziade.org
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
