[yjftsjthsd-h]

CentOS most certainly was shut down, and replaced with CentOS Stream, which is a similar product that went from at least as stable as RHEL and not having ABI breakage, to the beta for the next RHEL and having ABI breakage. Close enough for many uses, but not the same thing.

[mroche]

> went from at least as stable as RHEL and not having ABI breakage, to the beta for the next RHEL and having ABI breakage.

Please review the following resources before making statements about RHEL ABI compatibility in Stream:

---

RHEL ABI: https://access.redhat.com/articles/rhel8-abi-compatibility

RHEL Kernel ABI: https://access.redhat.com/solutions/444773

Kernel Sources (Module.kabi_<arch>):

  - RHEL 9: https://gitlab.com/redhat/centos-stream/rpms/kernel
  - RHEL 8: https://git.centos.org/rpms/kernel/blob/c8s/f/SOURCES

Pat Riehecky - Thinking About Binary Compatibility and CentOS Stream: https://www.youtube.com/watch?v=pVZuvoVau-0

---

As a future version of RHEL, CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist. I'll say it again:

CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist.

All packages that exist in Stream repos have passed the same internal gating test suites that RHEL has.

I'm sorry if this comes off as rough but it is very annoying seeing this "ABI incompatibility" statement be thrown around constantly without people fully understanding what it actually means in the context of RHEL. It is _not_ an all-encompassing policy that applies to the every part of the distribution the same like it would be implied for a library strictly following semver. There are levels and nuance, and some packages don't even make the list (which is why there are packages without a -devel subpackage).

It is okay to say that Stream may not be bug-for-bug identical to released versions of RHEL, but it will be ABI compatible.

[yjftsjthsd-h]

I was thinking specifically in the context of ZFS, which break on minor releases because kernel-internal symbols are not fully stable (unless I've seriously misunderstood https://github.com/openzfs/zfs/issues/11320). And since Stream is a rolling release, users will therefore experience breakage unless they specifically pin their kernel version (or possibly use DKMS). That's ABI breakage, and RH explicitly saying that it doesn't count doesn't stop it breaking stuff that would work in a non-rolling release.

[mroche]

Again, please review the Kernel ABI knowledge base resource I provided, specifically the last two bullet points in the article.

If OpenZFS happens to work throughout an entire RHEL minor release and they are using non-kABI symbols (which they are), that is not ABI compatibility: that's _luck_. It is in no-way-shape-or-form any kind of ABI compatibility the way it is defined for RHEL. You can't call RHEL kABI/ABI compatibility something it's not, it has an explicit meaning and definition.

Per the GH issue you provided the project explicitly stated they did their best to reduce as much as possible their reliance on non-kABI symbols. This was accomplished through symbols being added to the RHEL stablelist and OpenZFS reducing the symbols they actually use. If they didn't have to use non-kABI symbols there wouldn't be a problem. I've had NVIDIA kmod's from ELRepo fail _multiple_ times in a single minor release because non-kABI symbols changed, not to mention between minor releases. This is still not an example of RHEL kABI/ABI breakage.