We use both EPEL and SCL in my org. I didn't see this addressed in the email chain but I'm concerned about what'll happen if/when SCL includes python34. There are technical means to work around this but it fundamentally makes EPEL and SCL incompatible. I don't believe SCL is considered a layered product but maybe I'm wrong :)
Sent from my iPhone
On Apr 26, 2014, at 11:37 AM, Orion Poplawski orion@cora.nwra.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/18/2014 10:53 AM, Kevin Fenzi wrote: On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski orion@cora.nwra.com wrote:
So, we're just about ready to have python3-3.4 built in rawhide. This package builds fine in EPEL7 too. So, I'm proposing to build (and hopefully with help from others) maintain python3-3.4 for EPEL. Other options/considerations:
- We could build a python34-3.4 which provides python3 = 3.4.
This wou>>>
Perhaps as time goes by, it may make sense to package a later python3.X version if people really want to.ld allow us to have multiple
versions concurrently and to conceivably eventually switch a later version as the default. Not as easy to maintain as just another branch of the python3 package though. And we could do a hard cut at some later point with the python3 package method as well, so I'm not sure it buys us much there either.
I'd definitely prefer to try and do something where we aren't stuck with 3.4 for the rest of epel7's life.
- I looks like RedHat has been producing python33 SCLs, and
presumably will produce a python34 SCL eventually. Do we care about this? Personally I really want to simply be able to build my current Fedora python packages on EPEL7 with python3 versions just as it is done in Fedora and I don't think we can do with SCLs.
So, my preference is for the first and will start that soon unless there is consensus for a different approach.
I think a number of fedora infrastructure folks might have input here, but they are all out at pycon this week... so if you could hold off until next week at least and I will see about pointing them to the thread here?
kevin
Any further thoughts on this? I *think* with either python3 as 3.4 or python34 providing python3 = 3.4 you could later ship python35 providing 3.5, but perhaps it would be cleaner to start with python34. I confess to being lazy and not wanting to submit a new python34 package for review and have to maintain it in a separate git repo.
One interesting change from RHEL7 beta->rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x... of python3 actually using it (it seems to be using gdbm instead).
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6783089
Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNb0pgACgkQORnzrtFC2/s0UQCgnsD8R7nA9jSP4xrRuXDCL3yV nCsAnRjXZxDJ4xyU9Iez9C/mVWcAg4hT =i+E9 -----END PGP SIGNATURE----- _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel