Hoping to maintain python26 in EPEL5

[David Malcolm]

I'm interested in maintaining a build of python 2.6 for EPEL5,
parallel-installable with the system "python" (2.4 in EL5, which I
comaintain within RHEL).

I've adapted Fedora 13's Python specfile (which I comaintain), using
that specfile's ability to be built as a secondary Python version (with
"main_python" set to 0).  This sets "python26" as the name of the
package, and leads to it
owning /usr/bin/python2.6, /usr/lib(64)/python2.6, etc.

I've filed a review request for this package here:
https://bugzilla.redhat.com/show_bug.cgi?id=573151

but I wanted to give this a broader circulation, as I'm aware that a few
EPEL5 users already build their own python 2.6 RPMs, and I want to avoid
breaking those.

Some areas of possible clashes/incompatibility:
  - filesystem paths.  In my package I've taken the standard locations
(/usr/bin/python2.6 /usr/include/python2.6, etc), and so it's very
possible that my package will collide with pre-existing work in this
area
  - RPM names: similarly, this package is "python26", "python26-devel",
"tkinter26", etc
  - unicode: this package is built with "wide unicode" (UCS4), following
what we've done in RHL, RHEL and Fedora (and indeed, I believe since Red
Hat Linux 8), rather than the upstream default of UCS2.  This affects
ABI: if you've got extension modules built with UCS2 they won't work
with UCS4 (and vice versa).

Having said that, I'd expect that other RPM builds of "python26" built
with wide unicode (and without --py-debug) ought to be ABI-compatible
with this build (the devil may be in the details).

Would people find this useful to have in EPEL5?

Dave