EPEL Python 3.4 for 7
orion at cora.nwra.com
Sun Apr 27 03:13:12 UTC 2014
On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
> On Apr 26, 2014 11:37 AM, "Orion Poplawski" <orion at cora.nwra.com
> <mailto:orion at 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 at cora.nwra.com <mailto: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.
> I'm on vacation for a few days longer (fly home on Monday).
> I'd like to see us do a python3.4-3.4.x and then python3.5-3.5.x, etc.
> But that's motivated by not wanting to maintain a specific python3
> package for the life of rhel/epel. I'd rather we maintain two major
> versions at any one time so that people have a chance to transition
> their code but also limiting how many versions we'd have to maintain by
> rhel eol.
> The versioning scheme would be similar to the mediawiki packages in epel
> for this scheme.
>> One interesting change from RHEL7 beta->rc is the dropping of libdb4
>> which python3 currently BRs, although I cannot see any evidence in
>> of python3 actually using it (it seems to be using gdbm instead).
> Python 3 does use libdb although I think it can use libdb5. Python has
> a standard library that includes both libdb bindings and gdbm bindings.
Hmm, I see no evidence that it makes use of both as currently built. It
seems that gdbm is preferred and there are no dependencies on libdb*.
Submitted a python34 review here (I'm assuming that the 34 naming is
still preferred over 3.4?):
hopefully others will step up as co-maintainers.
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
More information about the epel-devel