Due to the fact RHEL 10.1 has been released, EPEL has already moved to EPEL 9.7 and 10.1.
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.
There is no guaranteed ETA so it will be ready when it’s ready. Expect at least somewhere around 1-2 weeks. Remember that this is a community effort, and everyone involved in the project has day jobs, families, etc. Also, RHEL 9.7 has also just been released, so means the team are doing two new releases at the same time.
So be patient everyone and just chill. In about a week or so, they should be ready.
EPEL has repos 10.0, 10.1, and 10.2 (while it has only 9).
This means that if EPEL repo definition points to 10.0, then Rocky 10 continues to function just like up to now. When Rocky 10.1 is released, then start to use URLs that point to EPEL 10.1.
The question is, how to make repo definition to point to 10.0 URLs?
With Rocky 9 there is no such possibility: EPEL has now started to add “built for 9.7” packages into the one and only EPEL 9.
If it goes by $RELEASEVER, then that is “9” or “10”. You can manually edit the EPEL repo files to replace that with 9.6 or 10.0 if you want…
EDIT:
Yes, EPEL 9 doesn’t use the $releasever, so not an option. For EPEL10 however it can be. The problem then is just remembering to revert if changing. Personally, I’d just live with the dnf output until Rocky 10.1 is released.
Yep, as per my original post, and also stated in the link provided that it can be at least 7 days/1 week and depending on things like life, family, jobs, results from testing, etc it could be longer than this - considering also that there is 9.7 AND 10.1 to work on at the same time. So everyone should at least allow for 1 - 2 weeks so that the team can do what they need to do.
An easier way than editing the repo files, is to just override the $releasever variable as follows:
echo "10.0" > /etc/dnf/vars/releasever
that will allow you to update your system, etc without the dnf errors. If using Rocky 9, then just do the override to 9.6 instead. Obviously you will have to remove the above file to return to normal behaviour afterwards when 9.7 and 10.1 get released.
Obviously that then affects all configured repos. If you want to apply it only to epel, then it would just mean editing the epel.repo file in /etc/yum.repos.d instead.
Starting from EL10, EPEL already provides repositories with the “z” suffix, which represent the 10 snapshot versions.
Right now you’re using Rocky Linux 10, but EPEL has already been updated to 10.1.
You can change the “10” in your epel.repo to “10z” instead.
I’ve been using RHEL clones since CentOS 4.x. Nothing new here. EPEL shits the bed about once a year, and that’s the price we have to pay for a free as in enterprise Linux.
Should do twice a year, on every point update. Perhaps every RHEL point update does not require equal amount of forced rebuilds? (E.g. Qt has not updated on every point update – KDE users tend to spot that.)
Anyway, with the releasever=10.0 the Rocky 10 users can temporarily pin to the EPEL 10.0, which is an improvement over all the previous EL major versions.
Currently investigating OpenSUSE as an alternative on the desktop. 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.
I’ve been testing several alternatives over the past couple weeks, and curiously enough OpenSUSE Tumbleweed looks like the most promising candidate.
9.7 is most likely being released today. But yeah, just use whatever suits your requirements. When you have third-party repositories, these things happen, and it doesn’t matter what distro you use. It can happen with Debian, Ubuntu and others too. You probably need to find a distro that includes everything you need without having to use third-party repositories, otherwise whatever distro you use, you will have these problems again for sure.
I guess I’m not understanding something here. Are you (re)installing “a few dozen desktop clients” on a daily or weekly basis?
If you have a working setup and “dnf upgrade” breaks for a few days or weeks, that should not prevent your previously working installations from continuing to work until everything gets synced up again.
Speaking for myself, I install the software that I need, set up my desktop, and I’m all set. If something causes the latest update to not work, it doesn’t affect what I’m doing with my computers since they’re already up and running with the software that I need.
Every desktop client has an Ansible playbook that runs once a day - or more exactly once a night at 03:30 AM. Sometimes I get asked to install a specific piece of software on all the computers, something like a math application or a mind mapping software. Normally I just add the corresponding task to the playbook, do a git push and then changes are applied… except now they aren’t. Somewhere along the way each playbook stops short because of missing EPEL dependencies.
enterprise Linux. 