Some versions of RHEL and RockyLinux have reached EOL #35
Conversation
| | 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 | |
There was a problem hiding this comment.
Is the jump from 7 to 9 intentional? RHEL 8 is still in mainline support for almost 5 years
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
-
not counting Debian 10, which you're already scheduled to drop as of today. ↩
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
No description provided.