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.
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
