"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).
-1. The installer should only take such action for new versions of the same package, not for packages that declare themselves replacements for others. In general, I think the two fields "obsoletes" and "conflicts" should only be used in an informational way. I'm not even sure whether it's a good idea to add them at all, due to the possibly negative effect of having package owners abuse these fields to push their particular variant of providing a solution to an application space. > 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. Agreed. The same is true for conflicting packages: even if packages A and D conflict, one application may use the package combination A,B,C while another may be using D,E,F - both without any conflicts. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 23 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig