Description of problem: Rust needs "cc" for linking, so it has "Requires: gcc". However, in bug 1482062 and bug 1482066 we found that it installed devtoolset-4-gcc instead of the expected base-OS gcc. DTS gcc isn't in the PATH without enabling the SCL, so rustc fails to invoke it. This seems to stem from DTS having "Provides:gcc = %{version}-%{release}". Since the base-OS gcc and several DTS gcc in the repo all provide some "gcc", yum apparently picks one at random. Version-Release number of selected component (if applicable): devtoolset-7-gcc-7.1.1-7.el7 (and AFAICS all past versions of DTS gcc) How reproducible: high Steps to Reproduce: 1. rhpkg clone rust-toolset-7-docker 2. cd rust-toolset-7-docker 3. rhpkg container-build --scratch Actual results: One of the devtoolset-*-gcc is installed to satisfy "Requires: gcc". Expected results: Ideally it should just install the base-OS gcc, as that will be in PATH. Additional info: Whatever we decide to do for devtoolset-7-gcc, I think we'll also need a solution that works with all of the past DTS present in the repos too. It may just be that rust.spec should have "Requires: /usr/bin/cc" instead.
More generally, I think we need to look at all the DTS packages and their Provides: lines to make sure they're sane WRT this problem.
It seems to me that we should drop %{?scl:Provides:gcc = %{version}-%{release}} from the gcc spec file. It's been there since the DTS 1.1 times and I do not find any justification why it's there. I've checked some other DTS packages (gdb, binutils, valgrind, dwz, systemtap, elfutils, strace) and I don't see the same Provides there. But that won't help right now because we're not able to change older DTS gcc. So, for now, I suppose let's use "Requires: /usr/bin/cc". It'd also be helpful to know, exactly, how yum finds the appropriate package specified in Requires.
I'm moving forward with what I proposed in Comment 3.
Should be fixed.
Both .el6 and .el7 source rpms of devtoolset-7-gcc-7.2.1-1 seem NOT to contain the troublemaker line: # cat rpmbuild/SPECS/gcc.spec | grep Provides Provides: liblto_plugin.so.0()(64bit) Provides: liblto_plugin.so.0 ---> VERIFIED.
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/RHEA-2017:3016