Showing content from http://mail.python.org/pipermail/python-dev/attachments/20121205/f4045280/attachment.html below:
<div><span style="color: rgb(160, 160, 168); ">On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:</div><blockquote type="cite"><div><div>How to use Obsoletes:</div><div><br></div><div>The author of B decides A is obsolete.</div><div><br></div><div>A releases an empty version of itself that Requires: B</div><div><br></div><div>B Obsoletes: A</div><div><br></div><div>The package manager says "These packages are obsolete: A". Would you like to</div><div>remove them?</div><div><br></div><div>User says "OK".</div></div></blockquote><div><br></div><div>Um, no. Even if the the author of A and B are the same person, you</div><div>can't remove A if there are other things on the user's system using</div><div>it. The above scenario does not work *at all*, ever, except in the</div><div>case where B is simply an updated version of A (i.e. identical API) --</div><div>in which case, why bother? To change the project name? (Then it</div><div>should be "Formerly-named" or something like that, not "Obsoletes".)</div></div></div></span></blockquote><div>You can automatically uninstall A from B in an automatic dependency</div><div>management system. I *think* RPM does this, at the very least</div><div>I believe it refuses to install B if A is already there (and the reverse</div><div>as well).*</div><div><br></div><div>There's nothing preventing an installer from, during it's attempt to</div><div>install B, see it Obsoletes A, looking at what depends on A and</div><div>warning the user what is going to happen and prompt it.</div><div><br></div><div>I think Obsoletes as is an alright bit of information. I think the biggest</div><div>flaw with Obsoletes isn't in Obsoletes itself, but is in the lack of a</div><div>Conflicts tag that has the same functionality (minimally refusal to</div><div>install both, possibly uninstall the previous one with a prompt to the</div><div>user).</div><div><br></div><div>Obsoletes has the semantics of a logical successor (typically renames)</div><div>while Conflicts should have the semantics of a competitor.</div><div><br></div><div>distribute would conflict with setuptools, foo2 would Obsoletes foo.</div><div><br></div><div>* I could be wrong about RPM's treatment of Obsoletes</div><div><br></div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div><br></div><div>Please, *please* see the previous Catalog-SIG discussion I linked:</div><div>this is only one of multiple metadata fields that were thoroughly</div><div>debunked in that discussion as completely useless for automated</div><div>dependency management.</div></div></div></span></blockquote><div>I don't see this in this thread, could you link it again? </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div>_______________________________________________</div><div>Python-Dev mailing list</div><div><a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a></div><div>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com">http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4