At 06:45 PM 8/25/2010 +0200, Alexis Métaireau wrote:
when two releases propose the same python modules to import,
Installation tools *always* have to detect this anyway -- a conflicts
field adds nothing new here.
Real world example: RuleDispatch and PyDispatcher both used the
"dispatch" package name at one point, but would not have if they'd
known the other existed. An installation tool would have had to
detect this, since there was no declared conflict.
or when they rely on the same configuration files for instance.
What does this mean, for a Python library? ISTM that it resolves to
either a file-level conflict, or a user-managed conflict.
Please, please provide an example for "Conflicts" that does *not*
fall into one of the following categories:
1. The installed files conflict,
2. Importing the provided code causes monopolization of a
process-level resource (e.g. a signal handler, trace hook, etc.),
3. The code monopolizes a system-level resource (e.g. a user ID,
port, directory, etc.)
For category 1, the installation tool has to be able to handle this anyway
For category 2, the installation tool need do nothing: it is possible
and sane to have both, say, Twisted apps and asyncore apps installed
on the same machine -- they will have different startup scripts and
will not import each other.
For category 3, the user has to take some kind of action to use both,
and/or is obliged to configure them in such a way as to use different
resources... but mere *installation* is not going to cause a problem.
In other words, none of the above is actually a use-case for having a
"Conflicts" field.
There is also the example Fred quoted about interfaces, here is the quote:
Fred hasn't yet explained this in a way that shows why it's not one
of the above three cases regarding Conflicts.
I agree that it would be nice if the way of the relation have been
changed, but Merwok pointed out that will force the maintainer of
the old release to create a new release just for that.
Here's the thing: so far I'm the ONLY person in the discussion who
has even offered an example of when Obsoletes would be used... and
for the two examples I gave, I would totally be willing to make a new
release for them to include that field, if there was some benefit
(e.g. user notification) to having the field.
"Conflict" and "Obsoletes" seems to be needed, here, as they cover
different use cases.
As far as I can tell, nobody has given any use cases for Conflicts or
Obsoletes that are not either:
1. A mere advisory message, or
2. Redundant with normal file installation conflict detection.
If the "Ham" release have been obsoleted by "Egg", and if "Spam"
relies on "Ham", and "Ham" is installed, that's fine, and the
installation can go on.
Now, if we try to install "Towel", that relies on "Egg", and we have
already "Ham" installed, we should just state there is a conflict here.
Why is there a conflict? This makes no sense whatsoever!
PEAK-Rules obsoletes RuleDispatch, but there is absolutely no reason
to not install both.
If you disagree with this, then we have a different meaning of the
word "Obsoletes"...
In which case, you need to show a concrete example of "Obsoletes"
using REAL Python packages, not made-up foobar examples, in order to
illustrate the definition where "obsoletes" means "shouldn't both be
installed".
By that, I mean that the releases should not be replaced by another
ones, even if the new ones obsoletes the old one.
In the specific example you gave, there isn't any conflict -- both
should be installed, and there is no need to even notify the user.
(Note that forked packages using the same API only conflict because
of *installing conflicting files* -- so if you're thinking of a fork
as your example here, it is leading you to confuse the ideas of
Obsoletes and Conflicts.)
the "conflict" field covers another type of conflict, also needed:
it would just be used in the way: "both A and B releases can't be
*installed* on the same time, whatever could be the cause".
The thing I haven't yet seen an example of is why they can't be
installed at the same time, that doesn't reduce to a file
installation conflict. AFAICT, anything else is *necessarily* a
runtime conflict, unless the intent is to cover installation of more
than just scripts and their libraries. (e.g. MvL's example of
creating user IDs)
But if that's the case, ISTM we should wait until we have the
software that does such installations *first* -- PEP 314 is an
example of what happens when you create the metadata spec before the
tools that use it -- nobody fills them in much, because they don't
know how they'll be used or have any reason to, and then the tools
probably end up needing different metadata anyway!
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
