EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Apr 26, 2014 11:37 AM, "Orion Poplawski" <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> 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.

(note, I likely won't reply again until tuesday when I get back from
vacation but please  feel free to ping me on irc or send email to get my
attention then.  I want to achieve similar end goals as you, I'm just busy
doing vacation-y, non-internet things until then.)

-Toshio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20140426/85cdbae4/attachment.html>