On 04/27/2014 07:37 AM, Aaron Knister wrote:
On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi <a.badger@gmail.com mailto:a.badger@gmail.com> wrote:
On Apr 26, 2014 8:27 PM, "Aaron Knister" <aaron.knister@gmail.com mailto:aaron.knister@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.
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".