This probably falls under the heading of “ignorant noob questions,” but I would like to clear up my understanding of whether I can or should use repos with my Rocky Linux installation.
Specifically, I would love some authoritative advice about my HP ProLiant DL360p Gen8. HP, or HPE, or whatever initials they’re called now, provides several sources of firmware updates and software packages. It’s easy to find repos for RHEL, and there is at least one repo intended for CEL (Community Enterprise Linux). The description for the CEL repo mentions Rocky Linux specifically, but the available distribution options in that repo only inlclude centos, fedora, opensuse and oracle.
Does the “100% bug-for-bug” compatibility with RHEL mean I can use the RHEL-specific repos directly? Is the Centos-specific repo the one I should be looking at? Should I be avoiding these repos altogether (doesn’t Rocky Linux include drivers)? Am I giving myself an unnecessary nosebleed by overthinking this?
Re Software packages:
It really depends on which ones you need. Some will be in the RL repos, others wont. You can search the repos for course. If not found in RL repos, then you need to search other ways of getting and installing them. Eg search RHEL repos or get and build the source code.
Re drivers
My understanding of drivers is that many are part of the Linux core and so not distribution specific. If RHEL included drivers for a specific machine, then Rocky will have them as well, since as you say, Rocky is compatible with RHEL.
Hope this helps.
But I would really think things over before doing anything…
First off, 3rd-party repos are just that, repos from sources that are not Rocky Linux, so the best place to ask these questions is from the people that provide the repos, so given that what you really should do is ask HP support channels and they should be able to point you in the correct direction. That said…
Rocky Linux is built and intended to be 100% bug for bug compatible with RHEL, so a repository that is intended to be used for RHEL should work just fine in Rocky Linux.
CentOS Linux was and Oracle Linux is also intended to be fully compatible with Rocky Linux (although Oracle has certain value adds, such as their “unbreakable” kernel). Also since, as you mention the description explicitly states that it’s the repo to use for Rocky Linux I would probably go with that one. The explanation here is that the repo was likely created before Rocky Linux was a thing so internally it doesn’t mention RL, but they have since tested it on Rocky Linux and found it to be compatible so they list RL in the description now. Keep in mind this is all speculation, though.
Also since these are 3rd party repositories nobody at Rocky Linux can officially recommend or support them since Rocky Linux has absolutely no control over the content of said repos. That doesn’t make the repos bad, however, it just means that we can’t say they’re good.
So to summarize, both repos will probably work fine, the CEL repo is the one you should probably choose because it explicitly mentions RL and you should ask HP for more authoritative advice on which one to use.
The other thing to consider, is that those repos that only mention other RHEL based releases, like CentOS etc, could be meant for older versions, like RHEL 7 based versions etc., & not yet include version 8 or newer which Rocky Linux is based on. So you should first ensure they also consider newer versions.
There are also “opposite”. For example, MS shares Teams via yum repo, but that repo is not for specific version. All recent packages work on EL8, but since last Summer packages have been built on some EL8 platform, while previously they were built on EL7. Result: latest packages do not install to RHEL 7, etc. In fact, they did halt ‘yum update’ on EL7 …
Generally speaking it’s not a good idea to use packages or repos that were built for a different platform or major release, so eg: repos built for CentOS 7 or SUSE Linux, etc.
The one exception is for packages that are very explicitly designed and built to be more platform agnostic. The way this is generally done is to statically compile the various libraries into the programs included in the packages, so they are not relying on dynamically linked libraries on the system. This, of course greatly bloats out the program and it requires the upstream project to track bugs in the libraries that they statically link and push out new releases of their software as necessary for that.
Now there are many programs that are a mixture of static and dynamic library linking. Most of these will still install on most Linux systems of teh same arch, but rely on certain very common libraries such as glibc and libstdc++ to be present and of a sufficiently high enough version to support the software that is being distributed. What happens here is that at some point the software vendor will decide to build their packages against a newer version of one of these dynamic libraries, and then you get an 8 year old distro such as CentOS 7 which won’t run them anymore because the glibc is too old now.
