Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 591958 - RFE - branch python3 to EL-6
Summary: RFE - branch python3 to EL-6
Alias: None
Product: Fedora
Classification: Fedora
Component: python3
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bohuslav "Slavek" Kabrda
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-13 14:53 UTC by Steve Traylen
Modified: 2014-04-07 09:05 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-04-07 09:05:24 UTC
Type: ---

Attachments (Terms of Use)

Description Steve Traylen 2010-05-13 14:53:53 UTC
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.


Comment 1 Dave Malcolm 2010-05-13 15:51:25 UTC
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)

Comment 2 Michał Piotrowski 2010-06-10 12:35:20 UTC
Is it possible to install Python 3.1 as python31 and provide links python3?

Comment 3 BJ Dierkes 2010-06-10 18:33:21 UTC
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).

Comment 4 Steve Traylen 2010-11-24 21:43:07 UTC
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
 pushd $ConfDir

 which is clearly doomed.

 Needs some work..

Comment 5 Toshio Ernie Kuratomi 2010-11-25 00:19:23 UTC
One disadvantage to using python3X naming is that it means on Fedora we do:
BuildRequires: python3-devel

but on EPEL, we do
BuildRequires: python31-devel

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.

Comment 6 BJ Dierkes 2012-01-09 21:51:52 UTC
Can we get an update on this?  Any plans to move forward with python3 in EPEL6?

Comment 7 ajs 2012-03-22 21:46:41 UTC
(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'.

Comment 8 Fedora Admin XMLRPC Client 2013-05-10 04:58:21 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 9 Bohuslav "Slavek" Kabrda 2014-04-02 14:27:20 UTC
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 [1] - 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.

[1] https://softwarecollections.org/en/scls/rhscl/python33/

Comment 10 Steve Traylen 2014-04-02 14:30:05 UTC
As the original submitted of this some long time ago I agree 

Software collections have removed the need to ever do this.


Comment 11 Bohuslav "Slavek" Kabrda 2014-04-07 09:05:24 UTC
Closing as wontfix as per comment 9.

Note You need to log in before you can comment on or make changes to this bug.