<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Apr 26, 2014, at 8:58 PM, Toshio Kuratomi &lt;<a href="mailto:a.badger@gmail.com">a.badger@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><p dir="ltr"><br>
On Apr 26, 2014 8:27 PM, "Aaron Knister" &lt;<a href="mailto:aaron.knister@gmail.com">aaron.knister@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; 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 :)</p>

<p dir="ltr">If red hat does the right thing and namespaces their scl packages then there shouldn't be any conflicts.&nbsp; Scls are intended to be isolated from system packages while epel packages are intended to integrate into the system.</p>

<p dir="ltr">-Toshio</p>
</div></blockquote><div>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.&nbsp;</div><br><blockquote type="cite"><div><span>_______________________________________________</span><br><span>epel-devel mailing list</span><br><span><a href="mailto:epel-devel@lists.fedoraproject.org">epel-devel@lists.fedoraproject.org</a></span><br><span><a href="https://admin.fedoraproject.org/mailman/listinfo/epel-devel">https://admin.fedoraproject.org/mailman/listinfo/epel-devel</a></span><br></div></blockquote></body></html>