Red Hat Bugzilla – Bug 591958
RFE - branch python3 to EL-6
Last modified: 2014-04-07 05:05:24 EDT
Please consider an EL-6 branch of python3.
The devel .spec file builds and installs on beta 6 with out modification.
Of course python3-distribute and similar would be needed as well.
Thanks for testing it. One possible technical snag: are the .pyc files generated with the correct version of python? What is the output of "file" about them?
I've thought about doing python3 in EPEL, but I'm wondering what EPEL's long-term goals should be for the usage of the "python3" namespace (both within the rpm database, and in terms of the filesystem e.g. /usr/bin/python3).
Python doesn't yet make any ABI guarantees between minor releases. So if we make "python3" in EPEL6 be python 3.1, then are we stuck with that for the lifetime of EPEL6? If so, if someone wants python 3.2, 3.3, etc, do we need python32 and python33 rpms? (etc). If that's the case, maybe this should be "python31", rather than "python3".
Alternatively, is python 3 still experimental enough that people would accept ABI bumps to 3.2 in the future?
One idea I had is that the build of the python3 src.rpm should generate "pythonMAJMIN" rpms, so that it would build python31, python31-libs, python31-devel etc. That way the minor version is explicit within the paths and rpm package names, and we have the option of revving the meaning of "python3" to e.g. python32 at a future date, whilst leaving the option of introducing a python31.src.rpm if people want to keep a 3.1 stack around.
(Perhaps this is something for the EPEL mailing list?)
I'm inclined to revisit my "rpm-pyconfig" idea
which would help a lot if we went with this approach. (I think I may rename it to "pyenvs" though)
Is it possible to install Python 3.1 as python31 and provide links python3?
I fully support the idea of making it 'pythonXY' same as with python26 in EPEL 5. It makes more sense, and leaves room for the next branch to join as well (python32, python33, etc).
Had another go at this today as it's starting to become significant for backporting things back from Fedora 14/15 to EPEL6.
Grabbing F15 build with no changes on EPEL6 you end up trying to
execute in the build:
mkdir -p $ConfDir
which is clearly doomed.
Needs some work..
One disadvantage to using python3X naming is that it means on Fedora we do:
but on EPEL, we do
Virtual provides can alleviate that but then... you're declaring that one of the python3X packages is "more equal" than the others (since it has the virtual provides) so the naming doesn't seem to make much sense then.
Can we get an update on this? Any plans to move forward with python3 in EPEL6?
(In reply to comment #6)
> Can we get an update on this? Any plans to move forward with python3 in EPEL6?
Yes, can we get an update? Does anyone have a publicly available .srpm, even if it is not 'perfect'.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm not opposed to this, but I have to declare I *won't* do this myself. From my POV it's insane amount of work and due to EPEL policies, we'd have to keep every python3X package (and all extension modules for it) basically for the whole lifetime of the given EPEL version. That's a maintenance nightmare if you realize that right now we already have 4 minor python3 versions.
I'd suggest using SCLs built in Copr and distributed through softwarecollections.org  - these don't need to follow EPEL policies and still everyone can utilize them in a sane way (and take their maintenance if noone else wants to maintain any more).
If someone wants to take the enormous burden of doing this in EPEL, I won't stand in his way, but I'm not doing this myself. I'll close this bug in a week or so, if nobody takes it.
As the original submitted of this some long time ago I agree
Software collections have removed the need to ever do this.
Closing as wontfix as per comment 9.