[Catalog-sig] PEP 345 Update

Alexis Métaireau alexis at notmyidea.org
Tue Oct 5 22:30:58 CEST 2010

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

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.


More information about the Catalog-SIG mailing list