<div class="gmail_quote">On Wed, Nov 21, 2012 at 12:44 PM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>
<br>Can anybody suggest an *actual* use case for "Obsoletes", and explain how it is supposed to work in software?  The last time this discussion came up, nobody had any use cases that stood up to the "how's that actually going to work and/or help?" test.  Here's a post of mine summarizing this and related points in the previous thread:<br>

<br>  <a href="http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html" target="_blank">http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html</a><br></div>The problem is that the above *makes no sense*.  "Torqued Python" and "Gorgon" are veiled pseudonyms for Twisted and Medusa....  and Twisted is not actually a plug-and-play substitute for Medusa, AFAIK.<br>
</div></blockquote><div><br>Sure. This is an RPM example, but exactly the same thing applies at the Python level.<br><br>One of the dependencies of PulpDist (a directory mirroring tool I wrote), is the Pulp project (originally just an RPM mirroring tool, but now with plugin-based support for mirroring other things). The upstream version of Pulp that I currently use is missing Kerberos login support, so I have patched that in via RPMs patching features.<br>
<br>To avoid messing up others sharing the internal yum repo where this is published, I actually use the Provides/Conflict/Obsoletes features of RPM to make sure my patched and renamed copy and the upstream version don't interfere with each other (and certainly can't be installed on the same system, as they would trample all over each other by attempting to install the same files).<br>
<br>Mostly though, these labelling tools are especially useful for internal forks and mergers - the ones you *don't* share with the wider internet, except perhaps in the form of upstream patches (For example: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=831937">https://bugzilla.redhat.com/show_bug.cgi?id=831937</a>). On a public index, drop-in replacements are *always* going to be controversial from a social point of view, which is why there are only two current examples on PyPI I am aware of (i.e. distribute vs setuptools and Pillow vs PIL). The first was essentially a hostile fork, while the latter started as an attempt to provide decent packaging support when the current maintainer didn't show any interest in doing so. In such cases, it is absolutely essential that the *forking* project is able to declare that it is a replacement for the original project. It is then up to the community to decide whether or not the claims of being a suitable replacement are valid, which will be shown most clearly in relative uptake numbers between the original project and the forked one.<br>
<br>I do consider it unfortunate that Python has only copied 3 of the 4 RPM dependency management fields 
(i.e. only Provides, Requires, and Obsoletes, without copying the more 
value neutral Conflicts) and I also prefer the "capability" terminology 
in the Fedora RPM guide that makes it clear that these are really 
arbitrary strings from a tooling point of view that only match the 
package name by convention.<br><br>Cheers,<br>Nick.<br> </div><div>-- <br></div></div>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>