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.
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
I do have a small snug though - .I use "provides" tags without version as in:
%package c++
Summary: C++ support for GCC
Group: Development/Languages
Requires: gcc%{gcc_suffix} = %{version}-%{release}
Requires: libstdc++%{gcc_suffix} = %{version}-%{release}
Requires: libstdc++%{gcc_suffix}-devel = %{version}-%{release}
Autoreq: true
Provides: gcc-c++
and gcc_suffix can be 474/484/492/etc.
This causes a conflict with binutils;
rpm -q --conflicts binutils
gcc-c++ < 4.0.0
and if trying yum install:
--> Processing Conflict: binutils-2.20.51.0.2-5.42.el6.x86_64 conflicts gcc-c++ < 4.0.0
--> Finished Dependency Resolution
Error: binutils conflicts with gcc484-c++-4.8.4-1.el6.x86_64
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.
Am I wrong and this is the expected behavior?
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.