Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Some versions of RHEL and RockyLinux have reached EOL #35

Merged
merged 1 commit into from
Jul 1, 2024
Merged

Some versions of RHEL and RockyLinux have reached EOL #35

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 5 additions & 9 deletions foundational-cxx-support-matrix.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
| C++ Version | >= 14 | 2022-07-01 | 2024-12-15 |
| CMake | >= 3.13 | 2023-06-01 | 2024-07-01 [^cmake] |
| Bazel | 6 LTS | 2023-04-18 | 2024-11-01 |
| GCC | >= 7.3.1 | 2022-07-01 | 2024-07-01 [^gcc] |
| GCC | >= 7.5.0 | 2024-07-01 | 2026-01-01 [^gcc] |
| Clang | >= 7.0.0 | 2023-06-01 | 2025-04-02 [^clang] |
| MSVC | >= 2022 | 2024-04-29 | 2027-01-12 |
| Apple Clang | >= 12 | 2022-07-01 | |
Expand All @@ -15,9 +15,8 @@
| Fedora | >= 39 | 2024-01-02 | 2024-12-01 |
| openSUSE | >= Leap 15.5 | 2024-01-02 | 2025-01-01 |
| Ubuntu LTS | >= 20.04 | 2023-06-01 | 2025-04-02 |
| RHEL | >= 7 [^rhel-7] | 2022-07-01 | 2024-07-01 |
| CentOS | 7 [^rhel-7] | 2022-07-01 | 2024-07-01 |
| RockyLinux | 8 | 2022-07-01 | 2024-06-01 |
| RHEL | >= 9 | 2024-07-01 | 2027-06-01 |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the jump from 7 to 9 intentional? RHEL 8 is still in mainline support for almost 5 years

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is intentional. This says "Maintenance Support":

https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates

https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase

Our reading is that RHEL 8 is not getting any new features or fixes.

Candidly, I think there is some mismatch between what it means to "support" an operating system and what it means for a library to "support" the same operating system. In the first case the vendor commits to fixing problems in the OS (when found and relevant, and serious enough). Sometimes they may go as far as extending the OS to support new hardware. In the second, the library developers commit to testing on that operating system for new releases, which include new features as well as bug fixes.

I think we need new words to describe how these two things differ.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how the exact level of OS support is all that relevant, what matters is how many users still exist. And generally there's a large tail of people on RHEL-derivatives, which is a constituency that many library and package maintainers aren't inclined to abandon.

This becomes even more important because the glibc baseline defined by the oldest supported Linux distro (which is generally RHEL) has a huge amount of impact in terms of what is actually distributable - compare the python's manylinux effort, or things like conda-forge (which just moved the global baseline to CentOS 7, for better or worse).

If you look at something like https://mayeut.github.io/manylinux-timeline/, the ecosystem is not ready to use a glibc lower bound of 2.31 (Ubuntu 20.04), much less 2.34 (RHEL 9)1. If Google projects like abseil, protobuf etc. start requiring such a "recent" (in distro terms) lower bound, we'll be in for a large amount of pain.

Footnotes

  1. not counting Debian 10, which you're already scheduled to drop as of today. ↩

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how the exact level of OS support is all that relevant, what matters is how many users still exist.

Our belief is that they can continue to use previous versions of the libraries that are known to work with that OS.

This becomes even more important because the glibc baseline defined by the oldest supported Linux distro (which is generally RHEL) has a huge amount of impact in terms of what is actually distributable - compare the python's manylinux effort, or things like conda-forge (which just moved the global baseline to CentOS 7, for better or worse).

Okay. That seems like something we should care about and it was not in our radar. I will discuss that internally.

If you look at something like https://mayeut.github.io/manylinux-timeline/, the ecosystem is not ready to use a glibc lower bound of 2.31 (Ubuntu 20.04), much less 2.34 (RHEL 9)1.

I looked, but I am not able to parse this. Can you shed some light on:

  • What version(s) of glibc would the Google projects need to support?
  • How would we decide to update that minimum version?

If Google projects like abseil, protobuf etc. start requiring such a "recent" (in distro terms) lower bound, we'll be in for a large amount of pain.

If we dropped distros, but continued to support specific glibc versions (never mind how we pulled such a magic trick): would that minimize the pain enough?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. That seems like something we should care about and it was not in our radar. I will discuss that internally.

Thanks a lot!

I looked, but I am not able to parse this.

Under "consumer statistics", see

image

Not every glibc version gets a separate colour, so 2.5 includes everything below the next colour, so 2.5-2.11. The cumulative number ("overall") is how many users are above a given glibc lower bound, which is what really matters for distribution.

How to read this is that, across all PyPI downloads on non-EOL Python versions (for the ~10k packages being analysed, but still a very broad sample), about 10% (=100-91.2) of linux users are on glibc<2.28, 15% on glibc<2.31, and 55% on glibc<2.34 (==RHEL 9). The picture looks even worse if not excluding EOL Python versions obviously.

  • What version(s) of glibc would the Google projects need to support?
  • How would we decide to update that minimum version?

Generally the glibc version in the last RHEL version that's not in extended support is a widely used lower bound. That would be 2.28 as of today, but obviously there are still many places that haven't adapted yet (and conda-forge is especially slow because some important classes of users like academic institutions are very slow with infra updates, but people try to maximize compatibility in any case).

Note that the glibc versions are really "discretized" by RHEL here, i.e. requiring 2.29 is basically indistinguishable from requiring 2.34 (next-greater RHEL), because a lot of the relevant infrastructure itself depends on RHEL-derivatives, see for example the summary + references in pypa/manylinux#1585.

If we dropped distros, but continued to support specific glibc versions (never mind how we pulled such a magic trick): would that minimize the pain enough?

Yes, if there would be a separate point for the glibc lower bound in the fundamental support matrix (i.e. it's tested somehow, or at the very least that bug reports for glibc versions greater or equal to that bound would be responded to), then that'd be very good already.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our belief is that they can continue to use previous versions of the libraries that are known to work with that OS.

As a though experiment, if abseil/grpc/protobuf started requiring glibc 2.34 tomorrow, conda-forge would either have to freeze the versions (not attractive), or duplicate the CI matrix for everything depending on these libraries into a before/after, and have separate "global" versions for these packages depending on cos7/cos8/cos9 glibc generation.

If it were "just" glibc 2.28 tomorrow, we might be able to get away with only building the dependent libraries for cos8+, because we cannot fight the rising upstream tide forever, but 2.34 is definitely wahahay too new for us.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started to circulate a proposal with my colleagues, starting with support for glibc >= 2.28. I included the topic for a meeting on 2024-07-08. I think this will go smoothly, will let you know either way.

| RockyLinux | >= 9 | 2024-07-01 | 2027-06-01 |
| Windows Server | >= 2022 | 2024-01-22 | 2026-10-13 |
| Windows Client | >= 10 | 2022-07-01 | 2025-11-01 |
| macOS | >= 10.15 (Catalina) | 2024-01-24 | 2024-07-01 |
Expand All @@ -27,15 +26,12 @@
vendor (or community, as applicable) extends or shortens the lifetime of the
dimension in question.

[^rhel-7]: We require the [devtoolset-7] toolchain (compiler, linker, build
tools, etc.) on RHEL 7 and CentOS 7.

[^cmake]: We support the oldest version of CMake that ships with one of the
supported distros. Currently that is CMake 3.13 as Debian 10 ships with this
version.

[^gcc]: Once RHEL 7 reaches EOL we will support the oldest version of GCC
that ships with one of the supported distros.
[^gcc]: Once openSUSE/Leap 15.5 reaches EOL we will support the oldest
version of GCC that ships with one of the supported distros.

[^clang]: We support the oldest version of Clang that ships with one of the
supported distros. Currently that is Clang 7.0 as Ubuntu 20.04 ships with
Expand Down