On 04/26/2014 06:55 PM, Toshio Kuratomi wrote: > > On Apr 26, 2014 11:37 AM, "Orion Poplawski" <or...@cora.nwra.com > <mailto: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 <mailto: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. >> > > 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 or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel