RetroSearch Browse

Wed Dec 5 08:46:11 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-December/122954.html

On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth <dholth at gmail.com (mailto:dholth at gmail.com)> wrote:
> > How to use Obsoletes:
> > 
> > The author of B decides A is obsolete.
> > 
> > A releases an empty version of itself that Requires: B
> > 
> > B Obsoletes: A
> > 
> > The package manager says "These packages are obsolete: A". Would you like to
> > remove them?
> > 
> > User says "OK".
> 
> Um, no. Even if the the author of A and B are the same person, you
> can't remove A if there are other things on the user's system using
> it. The above scenario does not work *at all*, ever, except in the
> case where B is simply an updated version of A (i.e. identical API) --
> in which case, why bother? To change the project name? (Then it
> should be "Formerly-named" or something like that, not "Obsoletes".)
> 
> 

You can automatically uninstall A from B in an automatic dependency
management system. I *think* RPM does this, at the very least
I believe it refuses to install B if A is already there (and the reverse
as well).*

There's nothing preventing an installer from, during it's attempt to
install B, see it Obsoletes A, looking at what depends on A and
warning the user what is going to happen and prompt it.

I think Obsoletes as is an alright bit of information. I think the biggest
flaw with Obsoletes isn't in Obsoletes itself, but is in the lack of a
Conflicts tag that has the same functionality (minimally refusal to
install both, possibly uninstall the previous one with a prompt to the
user).

Obsoletes has the semantics of a logical successor (typically renames)
while Conflicts should have the semantics of a competitor.

distribute would conflict with setuptools, foo2 would Obsoletes foo.

* I could be wrong about RPM's treatment of Obsoletes

> 
> Please, *please* see the previous Catalog-SIG discussion I linked:
> this is only one of multiple metadata fields that were thoroughly
> debunked in that discussion as completely useless for automated
> dependency management.
> 
> 

I don't see this in this thread, could you link it again? 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org (mailto:Python-Dev at python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121205/f4045280/attachment.html>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-December/122954.html below:

[Python-Dev] Keyword meanings [was: Accept just PEP-0426]