Bug 802051

Summary:	binutils-config and gcc-config should be more eager to switch to most recent toolchain version
Product:	Gentoo Linux	Reporter:	Sergei Trofimovich (RETIRED) <slyfox>
Component:	Current packages	Assignee:	Gentoo Toolchain Maintainers <toolchain>
Status:	RESOLVED WONTFIX
Severity:	normal	CC:	gentoo, sam
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
See Also:	https://bugs.gentoo.org/show_bug.cgi?id=802036 https://bugs.gentoo.org/show_bug.cgi?id=563614 https://bugs.gentoo.org/show_bug.cgi?id=847133 https://bugs.gentoo.org/show_bug.cgi?id=765664
Whiteboard:
Package list:		Runtime testing required:	---

Description Sergei Trofimovich (RETIRED) gentoo-dev

2021-07-13 19:34:06 UTC

Users who don't practice `emerge --depclean` often keep getting bitten by outdated toolchain (extreme case is bug #802036).

I think it's more natural to be more eager at switching to most recent toolchain version and have a way to use held back version when/if needed. That way users also have a higher chance to notice that new toolchain misbehaves before uninstalling one that did work.

Comment 1 SpanKY gentoo-dev

2021-10-11 06:23:28 UTC

i'm not aware of other system tools doing this (e.g. python, java, or other eselect wrappers), and i disagree that we should be mutating system state on the user automatically.  we've never done this in the history of Gentoo for these projects.

it's also a bit problematic if building things in parallel and the active version of tools suddenly changes.  we know binutils-config is not (currently) atomic -- see bug 563614.  but along those lines, probing one version and then executing a different one in the same build doesn't sound like a good idea.

so considering how often this seems to come up (not that often?), the deviation in standard Gentoo behavior & rough edges doesn't seem like the right trade-off.