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 _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
