[Catalog-sig] PEP 345 Update

[Alexis Métaireau]

Le 10/05/2010 11:35 PM, P.J. Eby a écrit :
> Quick summary of my previous comments on this point:
Thanks for that, it helps.

> * 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.) Foo
Even if we check for this kind of conflicts, a "conflict" field allows
us to do less operations, and to be quicker to find wrong cases, and
print something to the user.

If "foo 1.0" and "bar 1.0" are well known conflicting releases, we could
avoid the check of all the files to output an error.

Then, if the user really wants to install the two conflicting releases,
he could do so using some "--force" parameter, with installers, to avoid
the check of this "conflict" field.

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

So we agree there is conflicts that cannot be find a simple way at the
installation time (thanks for providing those examples). I agree that
the conflict field have to stand for a *possibility* of a conflict.
> 
> 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.
+1.
> 
> 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.

Yep. I've discussed yesterday with Toshio Kuratomi, who have clearly
indicated to me that at the distro level, they are packaging with
configuration files, and that the first way to avoid a conflict, when
possible, will be to configure it in a way it does not conflict anymore.

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

This lead to another question: Should we use exactly the same fields
with the same meanings, depending the context ? I think the answer is no.

For instance, we could interpret the "conflicts" field differently if we
want to install the software "as is" (in which case I think it's better
to trust it), than if we want to use that field in a distro context (as
the distros can provide configuration for the python distributions, they
can resolve those conflicts). BTW, if we provide a "conflict" field, it
can help them to detect such the simple way.

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

Any other ideas in favor of obsoletes, or in defavor of obsoleted-by,
before I start editing the PEP again ?

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

I think it's a good deal, and we could this way add such a check in the
distutils2 "check" command. That way, it'll allow people who want to
rely on "obsoleted" dists to do so.

Great, things goes on!

Alexis