Rocky 9.7, Rocky 10.1 and EPEL

[label]

@microlinux

EPEL being unusable for weeks on 9.x is a real showstopper here. I have a few dozen desktop clients with KDE from EPEL, and I’m stuck with these.

I know you guys work hard to release 9.7, but I guess this is a more fundamental problem that doesn’t really have a solution. I chose an Enterprise Linux precisely to avoid the moving target syndrome, and yet at every point release EPEL becomes a hot mess.

Your expectations (and blame) is misplaced. I don’t blame you for where your thoughts are, but you need to be realistic.

• EPEL follows RHEL. There should be no expectation that Rocky Linux (or others) will have their point release at the same time. It’s not possible.
• Before CentOS Stream existed, EPEL maintainers were literally forced to rebuild tons of packages as a result of dep/library/abi changes.
• With CentOS Stream, EPEL maintainers are able to build against the upcoming point release, thus making switching to the newest packages near seamless. This benefits RHEL and all other derivatives.

Everyone seems to forget about point 2 and how bad it really could be. It’s better now than how it was in the CentOS Linux days. Everyone also seems to forget that point 1 is a thing. If you cannot withstand waiting at a minimum, a week or more for our point releases, perhaps RHEL is better for your use case.

You don’t want to use RHEL? Alright, then investigate other distributions. Regardless of where you go, you’re going to run into these same exact issues, just with different invocations.

[FrankCox]

@microlinux

Somewhere along the way each playbook stops short because of missing EPEL dependencies.

If you’re running ansible on multiple computers every night and downloading software from official mirrors over-and-over, you might want to consider setting up your own local mirrors for the software you need instead.

Then you can control what’s available and keep things synchronized so your automation continues to work regardless of what’s happening “outside.”

[iwalker]

Rocky 9.7 is now released.

[jlehtone]

@label

• EPEL follows RHEL. There should be no expectation that Rocky Linux (or others) will have their point release at the same time. It’s not possible.
• Before CentOS Stream existed, EPEL maintainers were literally forced to rebuild tons of packages as a result of dep/library/abi changes.
• With CentOS Stream, EPEL maintainers are able to build against the upcoming point release, thus making switching to the newest packages near seamless. This benefits RHEL and all other derivatives.

Everyone seems to forget about point 2 and how bad it really could be. It’s better now than how it was in the CentOS Linux days. Everyone also seems to forget that point 1 is a thing.

Indeed. EPEL wants – and should – offer packets for elX_Y ASAP after RHEL X.Y is released. The other distros release X.Y on their own schedule. In order to release ASAP, EPEL must start builds as early as possible.

With CentOS Stream EPEL can start the rebuild for elX_Y before RHEL X.Y is released. That minimizes the delta between RHEL X.Y is release and access to EPEL packages for it.

With EPEL 10 the repo for X.Y is separate from the repo for X.(Y-1). Those, who could not (for any reason) upgrade to 10.1 the moment the RHEL 10.1 was out, could technically point to EPEL 10.0 repo and avoid most of the hassle. Therefore, the EPEL 10 is “better” than earlier generations.

---

However, EPEL is not the only third-party repo. There are others – with valuable content for some users – and each of them tackles the point updates in their own way. There are always “need to know” details (for those that use them).

RHEL has a price. Rocky has a price too. Not plain money though. Is there any distro that does not?

---

@FrankCox

you might want to consider setting up your own local mirrors for the software you need instead.

Then you can control what’s available and keep things synchronized so your automation continues to work regardless of what’s happening “outside.”

Isn’t that standard practice for many organizations? Separate testing setup that decides when/if new content is released to their production systems.

[iwalker]

@microlinux

I’ve been testing several alternatives over the past couple weeks, and curiously enough OpenSUSE Tumbleweed looks like the most promising candidate.

OpenSUSE Tumbleweed is a direct comparison to Fedora. So things may break. Fedora also has multiple desktops you can choose from, Gnome, KDE, Cinnamon, and others and they don’t rely on third-party repos so are going to just work. If you want to stay close to EL, then Fedora is about as close as you can get to RHEL that includes everything you will need without third-party repositories. Neither Tumbleweed or Fedora are unstable like they maybe were 20+ years ago, but then it was no different for using Debian Sid/unstable either. It’s better now than it used to be, but you wouldn’t rely on it for production servers.

OpenSUSE Leap are the only versions you can compare to RHEL/Rocky.

Had you been using RHEL/Rocky with Gnome desktop, then none of your issues would have occurred. Obviously there are people who don’t like Gnome, I’m one of them, but even then I choose a distro that has it built-in. I use Fedora on my laptop. Rocky I use for servers, because as soon as you start trying to get exotic with it when adding third-party repositories, then you have to remember that not everything will be in sync. Using it solely for servers, there are virtually no issues whatsoever. Assuming of course you haven’t pulled a ton of packages from EPEL, etc. But for most cases, the disruption is minimal.

[R_O_C_K_Y_L_I_N_U_X]

@iwalker

Rocky I use for servers, because as soon as you start trying to get exotic with it when adding third-party repositories, then you have to remember that not everything will be in sync. Using it solely for servers, there are virtually no issues whatsoever.

+1

Thanks @iwalker for writing that, my primary use case as well.

Tony

[u2604]

@iwalker

This means if you rely on packages from EPEL, then you will have to wait until Rocky 9.7 and 10.1 is released. Therefore, people using KDE, or KDE dependencies for apps they have installed, cannot update their system fully for the time being and will just have to ignore the dnf output.

@label

If you cannot withstand waiting at a minimum, a week or more for our point releases,

Ya, I can wait. Is there an existing automated way to signal to me that I need to wait and hold updates until RL is ready? I comfortable with DIY solutions with linux distro’s. If there isn’t already an automated means to handle these transitions, where should I start looking to make my own.

EDIT: My question is about future updates, not the current 9.7/10.1 update.

[iwalker]

@u2604

Ya, I can wait. Is there an existing automated way to signal to me that I need to wait and hold updates until RL is ready? I comfortable with DIY solutions with linux distro’s. If there isn’t already an automated means to handle these transitions, where should I start looking to make my own.

Easiest way is to run your own Satellite/Foreman server that is your local mirror. Then you control how often you sync it. Then when you know a future release is coming, just don’t sync it, and you won’t have any real issues as such. Then when released, you sync, and all sorted.

[u2604]

Thank you for the suggestion - a satellite server is something that I might want for other reasons as well. I’ll also have a look if there is a dnf config I can make that tags or pins installed EPEL packages as dependent on a RL version i.e. something that stops me from borking my installation(s) with auto update scripts.

[iwalker]

Creating /etc/dnf/vars/releasever with for example 9.7 would stop it going any higher, and restrict all the /etc/yum.repos.d/*.repo to 9.7 release instead of generic 9. Some may say it’s not recommended, but it really depends on what you are wanting to do. You can manually edit the repo files to restrict certain ones, eg; only EPEL, since if you create the dnf variable, it’s for all of them.