At 05:08 PM 8/27/2010 -0400, Tres Seaver wrote:
P.J. Eby wrote:
> I also suspect that if you ask those curator/integrators of system
> packages, that they will say that the information in these fields
> would be of little value to them in any case, as it's unlikely that
> the author will *know* about the kinds of conflicts they'd be
> concerned about in their packaging process. But it would certainly
> be worth asking them.
>
> More to the point though... I wonder whose idea it was to have these
> fields in the first place? Neither PEP 314 nor PEP 345 don't really
> say, "Oh, such and such people asked for these fields for thus-and-so
> use cases", and in the absence of such requestors and use cases, it
> would probably be best just to drop them entirely. (Unless of course
> Fred offers a description of what his actual use case for Conflicts
> is/was, and it doesn't fall into one of the categories previously
discussed.)
FWIW, I helped add those fields to PEP 345, in the context of making the
switch from "module / package"-centric values to distribution-centric
ones. The requirements came out of a sprint at PyCon 2009, with input
from both the Debian / Ubuntu Python packager (Matthias Klose) and one
of the Fedora packagers (Toshio Kuratomi).
Great - could we get them to join in on this discussion to explain
what it is that they want the creators of Python libraries to put in
these fields, and what they intend to do with the information once it's there?
At this point, we don't even know what that information is, really,
let alone whether it's something that a package author can actually provide.
(Btw, my comment about suspecting that they would say it's of little
value is because other Linux distro packagers have said on the
distutils list previously that author-provided dependency information
was generally of little use to them; I assumed the same would be even
more true for fields like these that require the author to step even
further outside their immediate knowledge.)
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
