Hide Forgot
Problem is that filtering out provides is only possible on RHEL7, not RHEL6. https://access.redhat.com/documentation/en-US/Red_Hat_Developer_Toolset/2/html-single/Software_Collections_Guide/index.html#sect-Software_Collection_Automatic_Provides_Requires_Filtering_Support
So it can be done on RHEL too, but differently: https://fedoraproject.org/wiki/EPEL:Packaging_Autoprovides_and_Requires_Filtering But note that this disables some of the internal rpm marking like file coloring which might break multilib installs. I think it is fine in this case because only the main elfutils package contains executables and that sub-package isn't multilib. All other packages have their executable files in separate directories and so should still be parallel installable. So when the fix is installed we need to double check a) no devtoolset-6-elfutils* subpackage Provides libelf, libdw.so or libasm.so. b) all elfutils sub-packages we ship multilib (x86_64 and i686 variants) can still be installed in parallel. Filter being tested right now: # The lib[64]/elfutils directory contains the private ebl backend # libraries. They must not be exposed as global provides. We don't # need to filter the requires since they are only loaded with dlopen. %if 0%{?fedora} >= 15 %global __provides_exclude ^libebl_.*\\.so.*$ %else # scl _libdir isn't actually the normal libdir, so don't provide any # libraries installed there. %{?scl:%filter_provides_in %{_libdir}/.*\.so$} %filter_provides_in %{_libdir}/elfutils/libebl_.*\.so$ %filter_setup %endif
After discussion with Martin we decided to try a different approach. We don't really trust the old (RHEL6) rpm to do the right thing with filter_provides_in. And the multilib conflicts because of the missing file coloring are scary. So instead of filtering out the provides we are now changing the SONAME version for libelf, libdw and libasm to "dts.1". This should work fine for the internal usage and signals that these packages can not be used to resolve a normal elfutils library provides. Note that since we do provide overrides (static linker scripts) for libelf.so, libdw.so and libasm.so in the -devel subpackages everything still works (and doesn't generate a requires) for anything building against these libraries (because they'll really get the static code).
On all the testing boxes I'm getting output similar to the following: ======= 7.4 Server x86_64 # eu-readelf --dynamic --notes /opt/rh/devtoolset-6/root/usr/lib64/lib{dw,asm,elf}-0.168.so | egrep '^/opt|SONAME' /opt/rh/devtoolset-6/root/usr/lib64/libdw-0.168.so: SONAME Library soname: [libdw.so.dts.1] /opt/rh/devtoolset-6/root/usr/lib64/libasm-0.168.so: SONAME Library soname: [libasm.so.dts.1] /opt/rh/devtoolset-6/root/usr/lib64/libelf-0.168.so: SONAME Library soname: [libelf.so.dts.1] 7.4 Server x86_64 # =======
Verified with devtoolset-6-elfutils-0.168-3.el[67].
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1149