[jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

[Andrew Hughes]

On 09:22 Wed 23 Jun     , David Holmes wrote:
> On 23/06/2021 5:38 am, Xin Liu wrote:
> > On Tue, 22 Jun 2021 17:20:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> > 
> >> It seems Ubuntu had bumped the version for GCC, so GHA started to fail with e.g.:
> >>
> >>
> >> The following packages have unmet dependencies:
> >>   g++-10-s390x-linux-gnu : Depends: gcc-10-s390x-linux-gnu-base (= 10.2.0-5ubuntu1~20.04cross1) but 10.3.0-1ubuntu1~20.04cross1 is to be installed
> >>   gcc-10-s390x-linux-gnu : Depends: cpp-10-s390x-linux-gnu (= 10.2.0-5ubuntu1~20.04cross1) but 10.3.0-1ubuntu1~20.04cross1 is to be installed
> >>                            Depends: gcc-10-s390x-linux-gnu-base (= 10.2.0-5ubuntu1~20.04cross1) but 10.3.0-1ubuntu1~20.04cross1 is to be installed
> >> E: Unable to correct problems, you have held broken packages.
> >> Error: Process completed with exit code 100.
> >>
> >>
> >> I believe we should just update to `10.3.0-1ubuntu1~20.04`.
> >>
> >> Additional testing:
> >>   - [x] GitHub Actions, package installation steps work
> >>   - [ ] GitHub Actions, the builds complete
> > 
> > .github/workflows/submit.yml line 175:
> > 
> >> 173:         run: |
> >> 174:           sudo apt-get update
> >> 175:           sudo apt-get install gcc-10=10.3.0-1ubuntu1~20.04 g++-10=10.3.0-1ubuntu1~20.04 libxrandr-dev libxtst-dev libcups2-dev libasound2-dev
> > 
> > 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
> 
> 
> 
> > -------------
> > 
> > PR: https://git.openjdk.java.net/jdk17/pull/120
> > 
> 

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)

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222