EPEL Python 3.4 for 7

Aaron Knister aaron.knister at gmail.com
Sun Apr 27 00:27:14 UTC 2014

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 at cora.nwra.com> wrote:
> Hash: SHA1
>> On 04/18/2014 10:53 AM, Kevin Fenzi wrote:
>> On Thu, 17 Apr 2014 22:49:04 -0600 Orion Poplawski
>> <orion at 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                  orion at cora.nwra.com
> Boulder, CO 80301              http://www.cora.nwra.com
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> nCsAnRjXZxDJ4xyU9Iez9C/mVWcAg4hT
> =i+E9
> _______________________________________________
> epel-devel mailing list
> epel-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel

More information about the epel-devel mailing list