Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1485002

Summary:	"Requires: gcc" may install dts-gcc which is not in PATH
Product:	Red Hat Developer Toolset	Reporter:	Josh Stone <jistone>
Component:	gcc	Assignee:	Marek Polacek <mpolacek>
Status:	CLOSED ERRATA	QA Contact:	Martin Cermak <mcermak>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	DTS 7.0 RHEL 7	CC:	bgollahe, codonell, fweimer, jakub, kanderso, law, mcermak, mnewsome, mpetlan, ohudlick, tstellar
Target Milestone:	alpha
Target Release:	7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	devtoolset-7-gcc-7.1.1-7.1.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-24 09:47:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Stone 2017-08-24 19:47:53 UTC

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.

Comment 2 Jeff Law 2017-08-24 20:59:54 UTC

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.

Comment 3 Marek Polacek 2017-08-25 12:46:54 UTC

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.

Comment 4 Marek Polacek 2017-08-28 15:59:14 UTC

I'm moving forward with what I proposed in Comment 3.

Comment 5 Marek Polacek 2017-08-30 09:12:10 UTC

Should be fixed.

Comment 7 Michael Petlan 2017-09-14 15:28:32 UTC

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.

Comment 9 errata-xmlrpc 2017-10-24 09:47:20 UTC

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