Re: EPEL Python 3.4 for 7

2014-04-27 Thread Aaron Knister

 On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
 
 
 On Apr 26, 2014 8:27 PM, Aaron Knister aaron.knis...@gmail.com 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-27 Thread Toshio Kuratomi
On Apr 27, 2014 9:37 AM, Aaron Knister aaron.knis...@gmail.com wrote:


 On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi a.bad...@gmail.com wrote:


 On Apr 26, 2014 8:27 PM, Aaron Knister aaron.knis...@gmail.com 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-18 Thread Kevin Fenzi
On Thu, 17 Apr 2014 22:49:04 -0600
Orion Poplawski 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




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