[Catalog-sig] PEP 345 Update

Alexis Métaireau ametaireau at gmail.com
Sat Aug 14 02:33:30 CEST 2010


 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.

> 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, it supports it, as the section on environment markers says, plus,
it makes sense.

> 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.
Dont now, in fact, we already have the Trove classifiers, and they seems
to be usable like this, IIRC. If you have others ideas, please propose :)

Cheers,
Alexis


More information about the Catalog-SIG mailing list