On Mon, Aug 23, 2010 at 5:28 AM, P.J. Eby <[email protected]> wrote: > At 04:09 AM 8/23/2010 +0200, Tarek Ziadé wrote: >> >> The fields descriptions are quite clear, Obsoletes is useful for >> reorganizing >> softwares into different releases names, whereas Conflicts marks a release >> to be incompatible with another one, > > If that's the case, then it should suffice to explain in the PEP that the > intent of this field is for an author/owner to describe reorganization of > their own software, rather than for one package to claim that it's a > replacement for another.
We can improve the Obsoletes-Dist description, sure. Notice that it will be misused if we don't add Conflict-Dist. That's basically why I wanted to add this field, as suggested by someone on IRC (sorry I forgot who) >> the PEP is about the metadata, not the softwares that will implement it. > > Which is why I've found the previous package metadata PEPs to be pretty > useless: they described fields in the abstract without much concrete > semantics. And thus, they were not worth writing software to parse, most of > the time. > > To put it another way, without suggested semantics, people will put whatever > they feel like in the fields, because they likewise have no idea of how the > information will be used, or what the consequences of entering that > information will be. The biggest problem imho, was that the dependencies where at the module level like Perl, and the semantics were completely artificial in Python. > In short: if it's not going to be used, why have it? And if it *is* going > to be used, why leave the semantics undefined? Sure, more explanation is always better Tarek -- Tarek Ziadé | http://ziade.org _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
