EPEL Python 3.4 for 7

[Orion Poplawski]

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
>>
> 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).
>>
> 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*.

> -Toshio

Submitted a python34 review here (I'm assuming that the 34 naming is
still preferred over 3.4?):

https://bugzilla.redhat.com/show_bug.cgi?id=1091657

hopefully others will step up as co-maintainers.

-- 
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