Re: EPEL Python 3.4 for 7

2014-04-28 Thread Aaron Knister 
I think it's a little unrealistic to expect the vendor to namespace their
packages although it would be nice and probably the right thing to do.
Could EPEL, as the 3rd-party layered product,  namespace theirs? (e.g.
epel-python34). It's more consistent with how other packages store version
numbers in the name (although as an aside, the smushing together of version
numbers without dots drives me a little crazy so part of me likes the dot
in python3.4).


On Sun, Apr 27, 2014 at 3:49 PM, Orion Poplawski wrote:

> On 04/27/2014 07:37 AM, Aaron Knister wrote:
> >
> > On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi  > > wrote:
> >
> >>
> >> On Apr 26, 2014 8:27 PM, "Aaron Knister"  >> > wrote:
> >> >
> >> > We use both EPEL and SCL in my org. I didn't see this addressed in
> >> the email chain but I'm concerned about what'll happen if/when SCL
> >> includes python34. There are technical means to work around this but
> >> it fundamentally makes EPEL and SCL incompatible. I don't believe SCL
> >> is considered a layered product but maybe I'm wrong :)
> >>
> >> If red hat does the right thing and namespaces their scl packages then
> >> there shouldn't be any conflicts.  Scls are intended to be isolated
> >> from system packages while epel packages are intended to integrate
> >> into the system.
> >>
> >> -Toshio
> >>
> > The contents are namespaced but the package names are not. We'll end up
> > with a package called python34 in each repo that are incompatible. The
> > SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL
> > package will have a prefix of /. Undoubtedly there will be packages in
> > EPEL (that aren't simply python34) modules that will require python34
> > that we'll be unable to use on systems with SCL because of the python34
> > package conflict. I wish RHEL had prefixed the package names with scl-
> > but alas they did not.
>
> What a pain.  FWIW:
>
> SCL 1.1:
> # repoquery --whatprovides python3
> # repoquery --provides python33
> python33 = 1.1-11.el7
> python33(x86-64) = 1.1-11.el7
> [root@vmrhel7 ~]# repoquery --provides python33-python
> python33-python = 3.3.2-10.el7
> python33-python(abi) = 3.3
> python33-python(x86-64) = 3.3.2-10.el7
>
> EPEL7 (as currently conceived):
> # repoquery --provides python34
> python(abi) = 3.4
> python3 = 3.4.0-2.el7
> python34 = 3.4.0-2.el7
> python34(x86-64) = 3.4.0-2.el7
>
> So yes, we'll likely conflict on the python34 name when python34 appears
> in SCL.  The EPEL packages will likely simply require python(abi) = 3.4
> and python3, so that may not be an issue.
>
> I suppose we could use "python3.4".
>
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 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
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-27 Thread Orion Poplawski 
On 04/27/2014 07:37 AM, Aaron Knister wrote:
> 
> On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi  > wrote:
> 
>>
>> On Apr 26, 2014 8:27 PM, "Aaron Knister" > > wrote:
>> >
>> > We use both EPEL and SCL in my org. I didn't see this addressed in
>> the email chain but I'm concerned about what'll happen if/when SCL
>> includes python34. There are technical means to work around this but
>> it fundamentally makes EPEL and SCL incompatible. I don't believe SCL
>> is considered a layered product but maybe I'm wrong :)
>>
>> If red hat does the right thing and namespaces their scl packages then
>> there shouldn't be any conflicts.  Scls are intended to be isolated
>> from system packages while epel packages are intended to integrate
>> into the system.
>>
>> -Toshio
>>
> The contents are namespaced but the package names are not. We'll end up
> with a package called python34 in each repo that are incompatible. The
> SCL package will have a prefix of /opt/rh/python34/root whereas the EPEL
> package will have a prefix of /. Undoubtedly there will be packages in
> EPEL (that aren't simply python34) modules that will require python34
> that we'll be unable to use on systems with SCL because of the python34
> package conflict. I wish RHEL had prefixed the package names with scl-
> but alas they did not. 

What a pain.  FWIW:

SCL 1.1:
# repoquery --whatprovides python3
# repoquery --provides python33
python33 = 1.1-11.el7
python33(x86-64) = 1.1-11.el7
[root@vmrhel7 ~]# repoquery --provides python33-python
python33-python = 3.3.2-10.el7
python33-python(abi) = 3.3
python33-python(x86-64) = 3.3.2-10.el7

EPEL7 (as currently conceived):
# repoquery --provides python34
python(abi) = 3.4
python3 = 3.4.0-2.el7
python34 = 3.4.0-2.el7
python34(x86-64) = 3.4.0-2.el7

So yes, we'll likely conflict on the python34 name when python34 appears
in SCL.  The EPEL packages will likely simply require python(abi) = 3.4
and python3, so that may not be an issue.

I suppose we could use "python3.4".


-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 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

Re: EPEL Python 3.4 for 7

2014-04-27 Thread Toshio Kuratomi 
On Apr 27, 2014 9:37 AM, "Aaron Knister"  wrote:
>
>
> On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi  wrote:
>
>>
>> On Apr 26, 2014 8:27 PM, "Aaron Knister"  wrote:
>> >
>> > We use both EPEL and SCL in my org. I didn't see this addressed in the
email chain but I'm concerned about what'll happen if/when SCL includes
python34. There are technical means to work around this but it
fundamentally makes EPEL and SCL incompatible. I don't believe SCL is
considered a layered product but maybe I'm wrong :)
>>
>> If red hat does the right thing and namespaces their scl packages then
there shouldn't be any conflicts.  Scls are intended to be isolated from
system packages while epel packages are intended to integrate into the
system.
>>
>> -Toshio
>
> The contents are namespaced but the package names are not. We'll end up
with a package called python34 in each repo that are incompatible.

Exactly.  That's why red hat has to do the right thing.

-Toshio
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-27 Thread Aaron Knister 

> On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi  wrote:
> 
> 
> On Apr 26, 2014 8:27 PM, "Aaron Knister"  wrote:
> >
> > We use both EPEL and SCL in my org. I didn't see this addressed in the 
> > email chain but I'm concerned about what'll happen if/when SCL includes 
> > python34. There are technical means to work around this but it 
> > fundamentally makes EPEL and SCL incompatible. I don't believe SCL is 
> > considered a layered product but maybe I'm wrong :)
> 
> If red hat does the right thing and namespaces their scl packages then there 
> shouldn't be any conflicts.  Scls are intended to be isolated from system 
> packages while epel packages are intended to integrate into the system.
> 
> -Toshio
> 
The contents are namespaced but the package names are not. We'll end up with a 
package called python34 in each repo that are incompatible. The SCL package 
will have a prefix of /opt/rh/python34/root whereas the EPEL package will have 
a prefix of /. Undoubtedly there will be packages in EPEL (that aren't simply 
python34) modules that will require python34 that we'll be unable to use on 
systems with SCL because of the python34 package conflict. I wish RHEL had 
prefixed the package names with scl- but alas they did not. 

> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-26 Thread Orion Poplawski 
On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
> 
> On Apr 26, 2014 11:37 AM, "Orion Poplawski"  > 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
>> > 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 DivisionFAX: 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

Re: EPEL Python 3.4 for 7

2014-04-26 Thread Toshio Kuratomi 
On Apr 26, 2014 8:27 PM, "Aaron Knister"  wrote:
>
> We use both EPEL and SCL in my org. I didn't see this addressed in the
email chain but I'm concerned about what'll happen if/when SCL includes
python34. There are technical means to work around this but it
fundamentally makes EPEL and SCL incompatible. I don't believe SCL is
considered a layered product but maybe I'm wrong :)

If red hat does the right thing and namespaces their scl packages then
there shouldn't be any conflicts.  Scls are intended to be isolated from
system packages while epel packages are intended to integrate into the
system.

-Toshio
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-26 Thread Toshio Kuratomi 
On Apr 26, 2014 11:37 AM, "Orion Poplawski"  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
> >  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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-26 Thread Aaron Knister 
We use both EPEL and SCL in my org. I didn't see this addressed in the email 
chain but I'm concerned about what'll happen if/when SCL includes python34. 
There are technical means to work around this but it fundamentally makes EPEL 
and SCL incompatible. I don't believe SCL is considered a layered product but 
maybe I'm wrong :)

Sent from my iPhone

> On Apr 26, 2014, at 11:37 AM, Orion Poplawski  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
>>  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.
> 
> 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).
> 
> Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6783089
> 
> 
> - -- 
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlNb0pgACgkQORnzrtFC2/s0UQCgnsD8R7nA9jSP4xrRuXDCL3yV
> nCsAnRjXZxDJ4xyU9Iez9C/mVWcAg4hT
> =i+E9
> -END PGP SIGNATURE-
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-26 Thread Orion Poplawski 
-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
>  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.

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

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6783089


- -- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNb0pgACgkQORnzrtFC2/s0UQCgnsD8R7nA9jSP4xrRuXDCL3yV
nCsAnRjXZxDJ4xyU9Iez9C/mVWcAg4hT
=i+E9
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-18 Thread Kevin Fenzi 
On Thu, 17 Apr 2014 22:49:04 -0600
Orion Poplawski  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




signature.asc
Description: PGP signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Python 3.4 for 7

2014-04-17 Thread Orion Poplawski 
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_update

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