[Catalog-sig] PEP 345 Update

[M.-A. Lemburg]

"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/