At 10:00 PM 8/23/2010 +0200, Martin v. Löwis wrote:
> 1/ The obsolete field could be used to say "this is the new version of
> X", like "the name of the project has changed". So the new version
> obsoletes the old one. Using this field, I think that the installers
> should remove the old releases (by prompting the user).
In case of "obsoletes", it _should_ also be possible to install both
of them simultaneously. Maybe some other other distribution depends
on the original one, and can't work with the new one.
Indeed. I have at least two cases in my own packages' history where
that would be relevant; I renamed my "ObjectRoles" package to
"AddOns" (including a module name change) and I have (essentially)
end-of-lifed RuleDispatch and replaced it with PEAK-Rules.
While in each case the newer package "obsoletes" the previous one, it
does not *conflict*, since there is no namespace overlap.
So, one should certainly not be prevented from installing the older
package, nor should the newer package be automatically substituted,
since in neither case does the "obsoleting" package provide a compatible API.
(This is another reason to clarify semantics of "Obsoletes", that I
hadn't actually thought of before... must an obsoleting package be a
drop-in replacement? If so, that implies that "Obsoletes" is always
also "Conflicts".)
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
