[Catalog-sig] PEP 345 Update

[P.J. Eby]

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