> In the same line of thought, I believe it would be > better to change the "obsoletes" field to "obsoleted-by", i.e. the > direction changes and gives the author of the obsoleted package > full control over what he thinks is a better version of his > package, rather than have some other author make that choice for > him.
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. I think that’s why the obsoletes field is defined by the release that supersedes, not the one that is obsoleted. Can someone tell what CPAN or Cabal have to deal with the replaces/conflicts/obsoletes/breaks problem? Regards _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
