On 01/21/2014 11:50 PM, Bohuslav Kabrda wrote:
----- Original Message -----
> On 01/15/2014 04:26 PM, Orion Poplawski wrote:
>> On 01/15/2014 12:16 AM, Bohuslav Kabrda wrote:
>>>
------------------------------------------------------------------------------
>>>
>>> Well a couple of other things would be needed beyond just
>>> maintenance:
>>>
>>> 1) Does providing python-3.4 mean that 3.4 will be the only python
>>> every
>>> provided by EPEL?
>>> 2) If it doesn't then how are upgrades from 3.4 to 3.5 to 3.6 going
to
>>> be
>>> handled?
>>>
>>> --
>>> Stephen J Smoogen.
>>>
>>>
>>> Well the problem is that once you provide a build for EPEL, you
shouldn't
>>> really do major updates [1], so it seems we would be stuck with whatever
>>> we
>>> build for 10+ years. I don't like that very much. We could probably do
>>> python3.4, python3.5 etc, but that'd probably require some modifications
>>> to
>>> dependency generators, etc... I'm not going to stay in anyones way to do
>>> this,
>>> but I won't do it myself.
>>>
>>> Slavek.
>>>
>>> [1]
>>>
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_version_...
>>>
>>
>> Well, quite frankly, I think anyone expecting 10 years of support for EPEL
>> packages is deluding themselves, some specific packages excepted. Users of
>> EPEL are probably best served by upgrading to newer versions of EL as soon
>> as
>> practical.
>>
>> My recommendation would be to ship python 3.4 as a "normal" python3
>> package.
>> The python folks appear to be committed to providing 5 years of security
>> fixes
>> for a release. This seems to be as long can be reasonably expected of
>> EPEL.
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 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.
- Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301
http://www.cora.nwra.com