JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

[Langer, Christoph]

Hi Andrew,

> > > One dummy question:
> > > Why do we need to specify the real package name here?
> > > If we install gcc-10, I think apt system will pick up the latest gcc-10 for us.
> >
> > IIRC the intent is to keep control over the gcc version and not
> > randomly update whenever the distro updates. Upgrading compiler
> > versions for the OpenJDK is actually a very involved process when done
> > properly and we often find code changes need to be made, or warnings
> > adjusted, when a new version of the compiler is to be used. This
> > approach forces us to check the new version is okay before switching
> > over to it. At least that is the theory. :)
> >
> > Cheers,
> > David
> >
> >
> 
> I'm in complete agreement with you as regards major versions of GCC. Fedora's
> eager adoption of them means we often encounter these early. JDK-8282231 is
> just the latest example from the introduction of GCC 12.
> 
> However, the GHA workflow in OpenJDK doesn't just depend on a major
> version of GCC - which is actually contained in the Ubuntu package name of
> gcc-9 or gcc-10 itself - but the full revision number, even down to local
> packaging changes.
> 
> I believe this is overkill and leads to valuable time being wasted on issues like
> JDK-8283778 where the GCC version itself didn't even change at all, just the
> Ubuntu version suffix.
> 
> Having just encountered this with 8u, I've filed JDK-8284772 there to just use
> the package name, which includes the major GCC version. That's already how it
> is depending on the x86_32 GCC, which hasn't suffered broken dependencies in
> the same way as x86_64.
> 
> I have yet to see an issue be specific to a minor GCC version bump, whereas the
> current setup is pretty much guaranteed to mean further fixes to the GitHub
> workflow every time the Ubuntu packager produces a new build.
> 
> I'm happy to submit the change for other JDK versions if there is interest, but I
> at least don't want to be encountering this in maintaining 8u (and certainly not
> having to add fixes to a release branch in rampdown, as happened recently
> with 11u)

I'm in full agreement with you and can't see any reason for but just additional trouble with hard maintenance of the GCC version suffix. I would love to see JDK-8284772 be done in head and backported to all active update releases. I had the same idea when doing JDK-8283778.

Best regards
Christoph