Inter-minor binary compatibility

Rocky Linux General
1

Hi all,

We (@evs) are working on transition from centos to rocky.
We were used to be in a highly frozen world. Being on a M.m versions for much too long…

When moving to Rocky9 I would like to be more dynamic on the M.m version, and release product with the last available minor version, and here come my question.

Is there a guarantee that between a 9.1 and a 9.2 the binary compatibility is present ? (saying my RPM done for 9.1 are still compatible/installable on my rocky 9.2).

We’ve done this previously on centos moving from 7.4 to 7.9 (big jump), very smoothly !

Thanks by advance !

2

Rocky Linux is no different from CentOS Linux; both have whatever the corresponding RHEL has.
The question is thus what does Red Hat guarantee about RHEL?

I don’ know.

I do know that el8.7/el9.1 updates had qt5 update from 5.15.2 to 5.15.3.
The qt5 is libraries and the *.2 → *.3 did break binary compatibility.
For all the packages in RHEL/Rocky that was no issue, because rebuilt versions were in the point update.
For third-party (e.g. KDE packages in EPEL) it did mean rebuild, rebuild!

On the other hand, I do know that some RPM’s built for el7 do install on el9 and the executables can run.

3

From what I see, RedHat guarantee API/ABI compatibility within a major version: https://access.redhat.com/articles/rhel8-abi-compatibility
Red Hat Enterprise Linux 9: Application Compatibility Guide - Red Hat Customer Portal

So should Rocky then if Rocky is indeed binary compatible with RedHat ?

4

Lets reiterate: Rocky has what RHEL has. if RHEL is compatible, then Rocky is compatible.
No more, no less.

EL9 package manifest lists qt5 as “level 2”: Package manifest Red Hat Enterprise Linux 9 | Red Hat Customer Portal
Yet, third-party packages (that depend on qt5) had to rebuild due to 9.1 update.
The level 2 should be “stable”, but observation is that it was not (for that specific case) in RHEL 9 (and hence in Rocky 9).

5

A package that depends on qt5 will have requirements like these:

libQt5Core.so.5()(64bit)
libQt5Core.so.5(Qt_5)(64bit)
libQt5Core.so.5(Qt_5.15)(64bit)
libQt5Core.so.5(Qt_5.15.3_PRIVATE_API)(64bit)

The last one is critical because it encodes the exact version used at build time. But you only get this requirement if you use the private apis declared in qt5-qtbase-private-devel. If you don’t do this the “level 2” guarantee should hold. (In other words: not every 3rd-party package needed a rebuild.)

1 Like
6