glibc: set next version

[iMichka]

See https://docs.brew.sh/Linux-CI#past-and-next-versions for ref

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

[MikeMcQuaid]

Would like @Bo98 to chime in before this is merged. He had some concerns about increasing the glibc version that I'd like to be spelled out a bit before.

[iMichka]

Happy to wait on @Bo98's comment :)

On this particular PR, we are not changing the glibc version yet. We just change the "next value", in preparation of the actual change, so this particular PR should be OK.

[MikeMcQuaid]

Ah, ok, fine with being merged as-is now and can get @Bo98's thoughts before we pull the trigger on the next version, thanks! 👍🏻

[Bo98]

#19248 should explain this better.

While brewed glibc does work well for what it does, it ultimately isn't problem free. We simply do not test against glibc on individual formulae and have received unfixed issue reports about things that doesn't quite work well:

• [linuxbrew] gcc-13 doesn't work on an Ubuntu distribution which targets glibc 2.31 homebrew-core#135068
• https://github.com/orgs/Homebrew/discussions/5421
• create-api and other swift packages fail to build from source on Ubuntu 20.04.5 LTS GitHub runner with linker error: undefined reference to __libc_csu_fini homebrew-core#113313

It's not unusable or anything but will break some user workflows and we offer no guarantees it works as we don't test it. 40% of our Ubuntu users are running 22.04. That's a lot to move to tier 2 support. Ubuntu 24.04 is not even a year old yet.

That's not to say we should never upgrade - we definitely should and not get into a situation where we're using 6-year-old versions of Ubuntu. But I also reckon we shouldn't necessarily upgrade too early either.

I think the questions we should ask every bump are:

• Are there formulae we are unable to ship/build properly because our glibc is too old?
• Are there formulae we are unable to ship/build properly because our GCC is too old?
• If yes to GCC but no to glibc, which GCC version do we need? Note that Ubuntu 22 can upgrade to GCC 12 easily as the runtime libraries are already GCC 12.

Basically: we should make sure we're actually benefiting from bumping the minimum version.
If we are benefiting: great we can go ahead about bumping this and coordinating a new minor release (since this is a breaking change). If we aren't benefiting: why bump?

[iMichka]

I see, I thought it was more a technical issue, but it is more about user experience and what support we want to give to our users.

Last time we had this discussion we updated the docs: https://docs.brew.sh/Linux-CI#past-and-next-versions

We plan to proceed with regular updates from 2022 onwards. We aim to use the latest Ubuntu LTS version for our CI.

We will start using the latest Ubuntu LTS version for our CI no earlier than 3 months after its release and, ideally, no more than 12 months after its release.

See also the reasons here: https://docs.brew.sh/Linux-CI#why-always-use-the-latest-version

I am happy to revisit this if needed. The idea is that the more we wait, the more work it is for us.

Another alternative would be to bottle for ubuntu 24.04 and 22.04, allowing for a smooth switch over a period of 3-5 years for our users.
This would mean doubling CI time (this is mostly an issue for self-hosted runner costs).

[p-linnane]

Fully agree with @iMichka on this.

EDIT: See below for additional context.

[Bo98]

Last time we had this discussion we updated the docs: https://docs.brew.sh/Linux-CI#past-and-next-versions

Worth noting this was before we updated glibc and got feedback from users on how it went. We updated the docs in early August 2022 (#13625) but proceeded with the changes in late August 2022 (#13733).

The main issue I have is we're not offering tier 1 support for older glibc and setting the minimum bar for tier 1 support to be a Linux distro released < 1 year ago seems extremely restrictive, unless we can demonstrate to users why it's worth it like we could last time (e.g. multiple formulae cannot be updated).

[p-linnane]

Worth noting this was before we updated glibc and got feedback from users on how it went. We updated the docs in early August 2022 (#13625) but proceeded with the changes in late August 2022 (#13733).

That makes things more interesting. In that case, I agree that we should be more cautious if it didn't go well the last time we did this.

[MikeMcQuaid]

We will start using the latest Ubuntu LTS version for our CI no earlier than 3 months after its release and, ideally, no more than 12 months after its release.

It sounds like this is what @Bo98 objects to.

@Bo98 what would you want this to say/be instead?

Another alternative would be to bottle for ubuntu 24.04 and 22.04, allowing for a smooth switch over a period of 3-5 years for our users.
This would mean doubling CI time (this is mostly an issue for self-hosted runner costs).

Strong 👎🏻 from me on doubling CI time for this.

It's not unusable or anything but will break some user workflows and we offer no guarantees it works as we don't test it. 40% of our Ubuntu users are running 22.04. That's a lot to move to tier 2 support. Ubuntu 24.04 is not even a year old yet.

Let's remember that "Tier 2 support" is, as of yet, currently undefined beyond a single issue.

Not a slam-dunk by any means but: it is worth noting that GitHub Actions' ubuntu-latest is already on 24.04.

If we are benefiting: great we can go ahead about bumping this and coordinating a new minor release (since this is a breaking change). If we aren't benefiting: why bump?

I don't really agree that, as-is, this would be a breaking change. The term "breaking change" is being thrown around a lot (too much, in my opinion) recently.

To answer your "why bump?" question, based on what @iMichka said above: we are going to have to bump at some point and the longer we wait, the harder it will be to do so.

My take is that it would be nicer to not have to wait until we have hard blockers due to migration. We should aim to plan to document clearly in advance (this was done) what our plans are and actually stick to them.

I agree that it sounds like we need to have more discussion before moving forward but, in my opinion, the best format of this discussion is not "let's do X", "let's not do X" but instead "let's do X", "let's do Y" instead, ideally with actual pull requests proposing changes to the relevant documentation.

[Bo98]

@Bo98 what would you want this to say/be instead?

Second latest is probably a reasonable middle ground. Remember at the time we switched last time we were previously using the 4th latest, which I agree is too long.

In terms of GCC, about ~15 months after Ubuntu 22.04 was released (a few months after we moved), GCC 12 did become available in the main repository (the runtime libraries have always been version 12) alongside GCC 11 so we should probably switch to that.

Not sure if the same will happen to 24.04 yet so hard to suggest docs change for that yet.

Let's remember that "Tier 2 support" is, as of yet, currently undefined beyond a single issue.

It reflects reality of our CI coverage though and how the solution to some issues has been to use a newer Ubuntu. We probably should have CI that tests formulae on brewed glibc but we don't.

I don't really agree that, as-is, this would be a breaking change. The term "breaking change" is being thrown around a lot (too much, in my opinion) recently.

We agreed it was last time but could try ship it in a patch release this time.

Swift dependents used to all break but I might have fixed them now. Main Swift formula might still break but that's better than last time.

we are going to have to bump at some point and the longer we wait, the harder it will be to do so.

This is one point I don't understand. The process to update does not change over time so it shouldn't get more difficult.

[MikeMcQuaid]

Second latest is probably a reasonable middle ground. Remember at the time we switched last time we were previously using the 4th latest, which I agree is too long.

Second latest Ubuntu release or Ubuntu LTS? If the latter: essentially this is "wait 2 years until after an LTS release", right?

In terms of GCC, about ~15 months after Ubuntu 22.04 was released (a few months after we moved), GCC 12 did become available in the main repository (the runtime libraries have always been version 12) alongside GCC 11 so we should probably switch to that.

Sounds like it's maybe ~15 months or conditional on this and a ~24 month max?

This is one point I don't understand. The process to update does not change over time so it shouldn't get more difficult.

Any technical process that's done less often becomes harder than a process that's done more often. If we had something that needs bumped once a month vs. once every 4 years: the chance of documentation/knowledge/maintainer attrition causing a fuck-up is dramatically higher.

That's not me saying "therefore we must do this now" but it is definitely an input into the equation here. Doing it entirely from a user-centric perspective doesn't account for this stuff and ends up with worse user outcomes.

[Bo98]

Second latest Ubuntu release or Ubuntu LTS? If the latter: essentially this is "wait 2 years until after an LTS release", right?

LTS yeah

Sounds like it's maybe ~15 months or conditional on this and a ~24 month max?

Probably yeah

Any technical process that's done less often becomes harder than a process that's done more often. If we had something that needs bumped once a month vs. once every 4 years: the chance of documentation/knowledge/maintainer attrition causing a fuck-up is dramatically higher.

I'm not suggesting a change in cadence, just a change in the baseline. When the baseline is aligned the cadence should be roughly every 2 years still.

[cho-m]

• If yes to GCC but no to glibc, which GCC version do we need? Note that Ubuntu 22 can upgrade to GCC 12 easily as the runtime libraries are already GCC 12.

GCC 12 could be worth considering as latest node (our most installed-on-request formula) no longer builds with GCC 11 - Homebrew/homebrew-core#207612

[MikeMcQuaid]

GCC 12 could be worth considering as latest node (our most installed-on-request formula) no longer builds with GCC 11 - Homebrew/homebrew-core#207612

This is good reasoning for moving to GCC 12 sooner rather than later.

What motivated the glibc version bump last time? Do we have any cases or pain points based on our glibc version? If we don't really have anything here: I think from the above I'd suggest we just bump GCC and not glibc this time (and document how you decide such things).

[carlocab]

What motivated the glibc version bump last time? Do we have any cases or pain points based on our glibc version? If we don't really have anything here: I think from the above I'd suggest we just bump GCC and not glibc this time (and document how you decide such things).

By my recollection: the bump to from 16.04 to 22.04 was 100% motivated by the GCC version. I don't think having an old glibc ever really caused us any problems.

[cho-m]

Yeah, I think newer glibc was mainly a side-effect of updating Ubuntu rather than something we specifically needed. Not aware of any core formulae that need a newer glibc > 2.35.

Some things we did get from glibc update:

• Newer C standard support. From glibc 2.23 -> 2.35 we got C11 threads in 2.28 which a couple Homebrew/core formulae use. Will note that most formulae still use more compatible Pthreads.
• CVE fixes. We could consider switching brew glibc to track Ubuntu releases if we want patches for these.

[MikeMcQuaid]

@Homebrew/maintainers given discussion here: my suggestion is that we:

• do not bump glibc at this time and reconsider in ~2 years for the next Ubuntu version bump
• we bump the GCC version

Any thoughts/objections/other ideas?