At 06:29 PM 8/24/2010 +0200, Ãric Araujo wrote:
I see two problems with this idea. Letâs say that Spam 1.0 is
released and obsoletes Ham, which has versions 0.1.3 and 0.2.1 (Ham
and Spam are from the same author): - Youâd have to release Ham
0.1.4 and 0.2.2 only to include the obsoleted-by field. - If a user
has Ham 0.1.3 and installs Spam 1.0, nothing says that Ham should be removed.
Has anyone shown a use case for why "Ham" *should* be removed? Ever?
We *do* have use cases for why "Ham" must NOT be removed, though:
PEAK-Rules obsoletes RuleDispatch, but code using RuleDispatch must
first be *changed* to use PEAK-Rules.
Therefore, an installation or path management tool cannot simply
substitute a dependency on one with a dependency on the other. (And
the same applies for ObjectRoles vs. AddOns.)
AFAICT, in no real-world use case yet presented here has there been a
reason to remove the "obsoleted" software at all, unless there is
*also* a corresponding Conflicts entry... in which case, the
Obsoletes entry is redundant.
This is a general property of Python modules: if you create a
non-conflicting, but obsolescing module, you *cannot* substitute
dependencies automatically, because the import targets will be
wrong. This means that "obsoletes" cannot have any semantic effect
on installation without there *also* being a file-level conflict.
Meanwhile, actual use cases for the Conflicts field are beginning to
become much narrower than they first appeared, since installation
tools are going to have to be able to detect undeclared
module/file/package conflicts anyway... so why have a conflicts field?
It's looking more and more like these fields are, at *best*, a
convenient place for sysadmins or other users to look for
purely-advisory messages about these things. (And in that case, the
people who actually *need* the obsolescence information are users of
the old package, not the new one!)
At worst, however, these fields are a waste of electrons and should
be dropped altogether.
("Obsoletes" really didn't have a very good rationale for being in
the previous metadata PEP (314), either. (I would borrow the time
machine and argue against it back then, but since I wasn't subscribed
to the Catalog-SIG mailing list in 2003, it would create a time
paradox to go back and try to post there now. ;-) ))
_______________________________________________
Catalog-SIG mailing list
Catalog-SIG@python.org
http://mail.python.org/mailman/listinfo/catalog-sig
