Hi, looking around in vault in the 9.0 baseos, I do see a few other kernels available. If we’re trying to just update 9.0 without going fully to 9.1 (there is some software that specifies 9.0 tested/compatible, and would pick up future even releases, not odd ones), is there a way to point only at relevant updates? I’m hoping to pick up bug and security fixes. But, if I do a general dnf update in a test environment, it takes the /etc/os-release to 9.1 Any pointers much appreciated.
Thank you,
The day 9.1 came out all updates to 9.0 ceased. There will never be any more updates to 9.0, not bugfixes, nothing. What you see in the vault is all that there is. Unless there are overriding reasons not to, you should go to 9.1 (and in due course 9.2) which ought to be compatible with all software, this is why it is an Enterprise distro.
1 Like
Do not try to “cherry-pick” only some packages from current (9.1) to your system. While RPM metadata does list most dependencies, the assumption is that all packages are from same point update – some unmentioned details might affect compatibility.
The real question is: is that merely because the vendor has not tested with every point update? (So they can say: untested, so we do not need to support.)
It is very rare to have so specific use of features that even slightest change breaks the program. Real features, not the string in /etc/os-release.
Thank you for the replies. The vendor’s rationale seems to be that the even releases have longer support than odd releases, so they don’t see a reason to take the effort for the odd ones. For me, at a minimum, I’d need to be able to version match kernel-devel and headers (separate from the vendor, to be able to build OpenOnload) as a dependency for the vendor and gcc. Since dnf groupinstall “Development Tools” takes current repo (from an unupdated test install of 9.0), I get a version mismatch. Is there a way to point dnf only at the vault directories? That would, though, leave me exposed to bug/security updates since. I believe RHEL does continue to update prior versions under support, but that’s a different ballgame. Otherwise, I suppose the only thing would be for us to adopt 9.1, and do our own testing for the vendor. I do not believe the difference 9.0 to 9.1 is anything like a change from the 8.x range, so I’d be hopeful that it wouldn’t be too much of an issue.
Thank you again,
Yes, see Extended Update Support (EUS) and Update Services for SAP
in Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal
In other words, the vendor assumes that all their customers also pay for RHEL, with EUS.
The options are thus:
- The software really does not function on odd point update versions. Paying for RHEL and EUS is a must
- The software does function on odd point update versions. (This is more likely.) You have the risk of vendor saying: “unsupported”, if you do get an issue
- Replace software with something more feasible
- ???
Yes, I’d say you’ve set out the possibilities. Is Alma ever considering replicating the RHEL extended support, as a curiosity? I’ll mark this done.
Thank again,
AIUI, no. The sources for the latest version are available, but the EUS sources are proprietary. It’s how RH makes its money.