[Python-Dev] Accept just PEP-0426

[Nick Coghlan]

On Wed, Nov 21, 2012 at 12:44 PM, PJ Eby <pje at telecommunity.com> wrote:

>
> 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:
>
>   http://mail.python.org/pipermail/catalog-sig/2010-October/003364.html
> 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.
>

Sure. This is an RPM example, but exactly the same thing applies at the
Python level.

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.

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).

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:
https://bugzilla.redhat.com/show_bug.cgi?id=831937). 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.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121121/5a18c4b9/attachment.html>