<div dir="ltr"><div><div>Far as I can tell the solutions are very similar - I used a suffix defined in the preamble, and modules to set PATH, LD_LIBRARY_PATH etc, SCL seems to use a prefix defined on the command line and requires implementing the enable script on a per package basis, but other than that the solutions seem identical.<br><br></div>Had I known of scl in advance, I'd probably use it. As it is, I prefer modules for the built in facilities for manipulating environment variables<br><br></div>I do have a small snug though - .I use "provides" tags without version as in:<br><br>%package c++<br>Summary: C++ support for GCC<br>Group: Development/Languages<br>Requires: gcc%{gcc_suffix} = %{version}-%{release}<br>Requires: libstdc++%{gcc_suffix} = %{version}-%{release}<br>Requires: libstdc++%{gcc_suffix}-devel = %{version}-%{release}<br>Autoreq: true<br>Provides: gcc-c++<br> <br><div>and gcc_suffix can be 474/484/492/etc. <br></div><div>This causes a conflict with binutils;<br>rpm -q --conflicts binutils<br>gcc-c++ < 4.0.0<br><br></div><div>and if trying yum install:<br>--> Processing Conflict: binutils-2.20.51.0.2-5.42.el6.x86_64 conflicts gcc-c++ < 4.0.0<br>--> Finished Dependency Resolution<br>Error: binutils conflicts with gcc484-c++-4.8.4-1.el6.x86_64<br><br></div><div>It seems to me from reading about the conflicts tag that this behavior is wrong. Without version in the provides, it should be assumed to be a virtual package, so conflict based on version should not happen.<br><br></div><div>Am I wrong and this is the expected behavior?<br></div><div><br></div><div>I don't know if the correct solution is to provide a version in the provides: tag (will it affect yum update, i.e. cause yum to replace gcc-c++ with gcc484-c++ even though there is no file conflict) or to force installation with nodeps, or something else.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 1:26 PM, Mat Booth <span dir="ltr"><<a href="mailto:fedora@matbooth.co.uk" target="_blank">fedora@matbooth.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 9 April 2015 at 10:56, Daniel Letai <span dir="ltr"><<a href="mailto:dani@letai.org.il" target="_blank">dani@letai.org.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks, It now works<br>
I also had to move it prior to the 1st %description tag.<br>
<br>
BTW, I have built a gcc toolchain rpms (gmp, mpfr, mpc, cloog, isl, osl and gcc - each in it's own rpm) using environment modules to allow multiple version co-existence.<br>
<br>
It works well enough internally in our own production environment, I'm wondering if anyone else might have use of such an environment.<br>
<br>
The %doc was the last issue.<br>
<br></blockquote><div><br></div></span><div>It sounds like you have very nearly re-invented "software collections" because it does something similar: <a href="https://www.softwarecollections.org/en/" target="_blank">https://www.softwarecollections.org/en/</a><br><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
On 04/09/2015 11:34 AM, Ville Skyttä wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Apr 9, 2015 at 10:13 AM, Daniel Letai <<a href="mailto:dani@letai.org.il" target="_blank">dani@letai.org.il</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
$ cat sample_rpm.spec<br>
</blockquote>
[...]<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
global _defaultdocdir /opt/sample_rpm/share/doc<br>
</blockquote>
Try %global instead of global.<br>
--<br>
packaging mailing list<br>
<a href="mailto:packaging@lists.fedoraproject.org" target="_blank">packaging@lists.fedoraproject.<u></u>org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/packaging" target="_blank">https://admin.fedoraproject.<u></u>org/mailman/listinfo/packaging</a><br>
</blockquote>
<br>
--<br>
packaging mailing list<br>
<a href="mailto:packaging@lists.fedoraproject.org" target="_blank">packaging@lists.fedoraproject.<u></u>org</a><br>
</span><a href="https://admin.fedoraproject.org/mailman/listinfo/packaging" target="_blank">https://admin.fedoraproject.<u></u>org/mailman/listinfo/packaging<span class="HOEnZb"><font color="#888888"><br clear="all"><br>-- <br></font></span></a><span class="HOEnZb"><font color="#888888"><div><a href="https://admin.fedoraproject.org/mailman/listinfo/packaging" target="_blank">Mat Booth<br></a><a href="http://fedoraproject.org/get-fedora" target="_blank">http://fedoraproject.org/get-fedora</a></div>
</font></span></blockquote></div>
</div></div>
<br>--<br>
packaging mailing list<br>
<a href="mailto:packaging@lists.fedoraproject.org">packaging@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/packaging" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/packaging</a><br></blockquote></div><br></div>