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 <or...@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 >> <or...@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/x86_64/build.log > 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 or...@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 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
