Le 10/05/2010 06:05 PM, P.J. Eby a écrit : > If a field doesn't have clear semantics, there is no point in allowing > people to specify it - it is literally adding a new field to a database > and inviting the entire world to put whatever they want in it... which > means you end up with a worthless database (at least in that column).
That's true. BTW, we dont agree on the utility of this field because we're not sure how it's needed to be considered. It could be simple, for packagers, to say: "okay, I *know* that my release is not compatible with another specific one". We have to think about this conlict scope, because we do not agree on that too: are the fields made for "installation scope", or for "running scope". I mean: is that "conflict" field means that "it's impossible to *install* the both distributions at the same time", or that "it's impossible to *run* them at the same time" ? And, maybe do we need a way to specify those two cases. After reading a bit again this thread, it comes that we have another proposition, of an "obsoleted-by" field, which can replace the "obsoletes" one (for renames). To resume the pro and the cons of each: 1/ obsoleted-by: - Pro: It allows the package owners to manage what will obsolete they releases; And avoid malicious usages. - Cons: It will need package owners to re-issue a distribution with this changes. 2/ obsoletes: - Pro: Don't need to re-issue a distribution. - Cons: Anyone can tell he obsoletes anyone else package. What do you think we should do with that ? That's a fact that this PEP need to be revamped a bit, with the questions we have introduced in mind. > While this isn't the first metadata PEP with this problem, it would be > nice if the previous one were the last. ;-) Yep, so let's work on this problems to fix them. Alexis _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
