Package repository issues

Rocky Linux Help & Support
1

We run a Rocky Linux HPC cluster, currently we’re at 9.7

On Sun 28th June we attempted to update to 9.8 and started getting DNF errors such as:

Last metadata expiration check: 3:18:34 ago on Mon 29 Jun 2026 08:07:09 AM SAST.
Error:
Problem: cannot install both mesa-filesystem-25.2.7-4.el9.x86_64 from appstream and mesa-filesystem-25.0.7-5.el9_7.x86_64 from @System

* package mesa-va-drivers-25.0.7-5.el9_7.x86_64 from @System requires mesa-filesystem(x86-64) = 25.0.7-5.el9_7, but none of the providers can be installed
* cannot install the best update candidate for package mesa-filesystem-25.0.7-5.el9_7.x86_64
* problem with installed package mesa-va-drivers-25.0.7-5.el9_7.x86_64
  (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

and

Error:
Problem 1: package qt6-doctools-6.6.2-4.el9.x86_64 from @System requires libclang-cpp.so.20.1()(64bit), but none of the providers can be installed

* package qt6-doctools-6.6.2-4.el9.x86_64 from @System requires libclang-cpp.so.20.1(LLVM_20.1)(64bit), but none of the providers can be installed
* package qt6-doctools-6.6.2-4.el9.x86_64 from @System requires libclang.so.20.1()(64bit), but none of the providers can be installed
* package qt6-doctools-6.6.2-4.el9.x86_64 from @System requires libclang.so.20.1(LLVM_13)(64bit), but none of the providers can be installed
* cannot install both clang-libs-21.1.8-2.el9.x86_64 from appstream and clang-libs-20.1.8-3.el9.x86_64 from @System
* cannot install the best update candidate for package qt6-doctools-6.6.2-4.el9.x86_64
* cannot install the best update candidate for package clang-libs-20.1.8-3.el9.x86_64
  ...
  \[snip\]
  ...
  Problem 6: package clang-devel-21.1.8-2.el9.x86_64 from appstream requires libclang-cpp.so.21.1()(64bit), but none of the providers can be installed
* package clang-devel-21.1.8-2.el9.x86_64 from appstream requires libclang.so.21.1()(64bit), but none of the providers can be installed
* cannot install both clang-libs-21.1.8-2.el9.x86_64 from appstream and clang-libs-20.1.8-3.el9.x86_64 from @System
* cannot install both clang-libs-21.1.8-2.el9.x86_64 from devel and clang-libs-20.1.8-3.el9.x86_64 from @System
* problem with installed package qt6-qttools-devel-6.6.2-4.el9.x86_64
* package qt6-qttools-devel-6.6.2-4.el9.x86_64 from @System requires qt6-linguist = 6.6.2-4.el9, but none of the providers can be installed
* package qt6-qttools-devel-6.6.2-4.el9.x86_64 from epel requires qt6-linguist = 6.6.2-4.el9, but none of the providers can be installed
* package qt6-linguist-6.6.2-4.el9.x86_64 from @System requires libclang-cpp.so.20.1()(64bit), but none of the providers can be installed
* package qt6-linguist-6.6.2-4.el9.x86_64 from @System requires libclang-cpp.so.20.1(LLVM_20.1)(64bit), but none of the providers can be installed
* package qt6-linguist-6.6.2-4.el9.x86_64 from epel requires libclang-cpp.so.20.1()(64bit), but none of the providers can be installed
* package qt6-linguist-6.6.2-4.el9.x86_64 from epel requires libclang-cpp.so.20.1(LLVM_20.1)(64bit), but none of the providers can be installed
* cannot install the best update candidate for package clang-devel-20.1.8-3.el9.x86_64
  (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

This is consistent over all of our 80 servers. We’ve been running Rocky for several years and have never encountered this before.

  • Is anyone else seeing this?

  • How safe is it to add --allowerasing?

  • Is this an issue with maybe just our local mirror? Doesn’t seem like it as I tried one dnf update directly against rockylinux.org

regards

2

See also
https://forums.rockylinux.org/t/rocky-linux-9-8-is-missing-mesa-va-drivers-rpm/20592/3

3

I’ve encountered a few errors like your first one where there’s a change in package suffixes (e.g. el9_7 versus just el9) and in (I think) all cases, I’ve been able to resolve them by swapping packages.

For example:

dnf swap proj-data-9.6.0-3.el9_7.noarch proj-data-9.6.0-3.el9.noarch

The second error you’ve listed involves EPEL, and it’s the opposite of what I’m used to seeing – i.e. it looks like the some of EPEL’s qt6 packages have not yet been built against 9.8.

Personally, I’d recommend against --allowerasing. It’s more likely to break something than really help you (unless you have a really good handle on exactly what’s going to be erased).