[Catalog-sig] PEP 345 Update

[P.J. Eby]

At 09:30 PM 10/5/2010 +0100, Alexis Métaireau wrote:
>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.


Quick summary of my previous comments on this point:

* In the simplest case, installation conflict equals conflicting 
files -- which any installation tool *must* be able to handle on its 
own. (Otherwise, it will break in the event of an undeclared conflict.)

* The only way for other installation conflicts to exist is if the 
installation tools is going to set up user IDs, cronjobs, etc., which 
are properly *application configuration*, rather than software.

* The same is true for runtime conflicts: they once again represent 
*configuration* conflicts -- i.e., in general, to have a runtime 
conflict between two pieces of code, they must have overlapping 
configurations, or be non-configurable.

In short, the only way to specify that a piece of software *does* 
conflict with another one at runtime, is if you *fully specify the 
configuration* of both pieces of software; e.g., if neither package 
allows any configuration whatsoever of ports used, user IDs, 
etc.  All other conflicts can be reduced to file-level conflicts.

Because of this, the conflict field can have no function except to 
notify a user of the *possibility* of a conflict.  An installation 
tool MUST still check for file conflicts, even if they are not 
declared, and MUST still allow the user to install software that is 
declared conflicting, but which does not include any file-level 
install-time conflicts.

The reason that existing OS-level packaging tools have enforced 
"conflict" fields is because they are *system integration* packaging 
tools, not generic software installation.  A distro like Fedora or 
Ubuntu represents a set of predefined application *configurations*, 
not just raw software.  Because of this, they can (and should) 
enforce conflict declarations, because they know precisely how each 
package is configured.

However, two packages that conflict in the Fedora configuration, do 
not necessarily conflict in the Ubuntu configuration, nor vice 
versa.  This means that a Python-supplied "conflicts" field can only 
be advisory at best.


>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.

"Obsoleted-By" is a field with actual use cases; i.e., there are 
packages I have right now that I wouldn't mind pushing a new 
distribution of to specify their "Obsoleted-By" fields.  (Assuming I 
were using a sufficient distutils version, of course.)

"Obsoletes", on the other hand, has not received any similar support 
in this thread.

Of course, in either case the field must still be for human 
consumption (and tool warning messages) only.  If a developer 
declares a dependency on an obsolete package, they should be 
notified; but an end-user who's merely installing the package in 
order to satisfy another package's requirements doesn't need to be warned.