Problem 1: package gd3php-2.3.3-9.el9.remi.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from @System
cannot install both libavif-1.1.1-2.el9.next.x86_64 from epel-next and libavif-0.11.1-5.el9.x86_64 from epel
cannot install the best update candidate for package libavif-0.11.1-5.el9.x86_64
cannot install the best update candidate for package gd3php-2.3.3-9.el9.remi.x86_64
nothing provides libdav1d.so.6()(64bit) needed by libavif-0.11.1-0.x86_64 from remi-safe
Problem 2: package php-gd-8.3.33-1.module_php.8.3.el9.remi.x86_64 from @System requires libgd.so.103()(64bit), but none of the providers can be installed
package gd3php-2.3.3-9.el9.remi.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
package gd3php-2.3.3-9.el9.remi.x86_64 from remi-safe requires libavif.so.15()(64bit), but none of the providers can be installed
package gd3php-2.3.3-8.el9.remi.x86_64 from remi-safe requires libavif.so.14()(64bit), but none of the providers can be installed
package libavif-0.11.1-5.el9.x86_64 from @System requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
package libavif-0.11.1-5.el9.x86_64 from epel requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
package libavif0.10-0.10.1-2.el9.x86_64 from epel requires libSvtAv1Enc.so.0()(64bit), but none of the providers can be installed
cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from @System
cannot install both svt-av1-libs-2.3.0-2.el9.next.x86_64 from epel-next and svt-av1-libs-0.9.0-1.el9.x86_64 from epel
cannot install the best update candidate for package svt-av1-libs-0.9.0-1.el9.x86_64
cannot install the best update candidate for package php-gd-8.3.33-1.module_php.8.3.el9.remi.x86_64
nothing provides libdav1d.so.6()(64bit) needed by libavif-0.11.1-0.x86_64 from remi-safe
(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)
followed some online AI suggestion. None help to resolve the problem
EPEL Next is an additional repository that allows package maintainers to alternatively build against CentOS Stream. This is sometimes necessary when CentOS Stream contains an upcoming RHEL library rebase, or if an EPEL package has a minimum version build requirement that is already in CentOS Stream but not yet in RHEL.
That is, The EPEL Next [9] is a repository for CentOS Stream 9. It is not for Rocky Linux 9.
You should use only repositories, whose packages are built for Rocky Linux 9.
Well, it was explained. You cannot use epel-next repository on Rocky Linux. Once it’s disabled you don’t have a problem - which you found already as you posted about it.
I’ve got this using php-gd from remi repository, it’s tied to the old libavif and not the new one that’s been released from epel.
Removing php-gd does resolve the problem and the newer libavif can then be installed, but this is purely a dependency issue for packages used from alternative repositories not managed/maintained by the Rocky team.
The System in @System is not a repoid. Two ways that might reveal from which repo the package was installed from:
dnf --showduplicates list libavif
dnf history info libavif | grep libavif
If the installed package is not from EPEL, then one can focus on conflicts between two repos.
If the installed package is also from EPEL, then the two package versions in EPEL have an issue.
The @repoid are all in the “Installed Packages” section. The @ indicates that package is installed
Repoid without the @ shows that package is in repository “repoid”, not installed.
The installed 0.11.1-5.el9 looks like newer version than the 0.11.1-0 in remi-safe.
Since you have remi-safe repo, you probably have installed something from it and that
something requires libavif with some version.
Was there only one line of error message about libavif?
@iwalker did mention one package that his system had, which was from Remi’s repo and did block libavif.
One can test:
dnf --disablerepo=remi-safe up
if mere availability of packages in repo is a blocker, then hiding that repo for the duration of the command would make a difference.
Also,
dnf rm libavif
will show what packages would go with that removal (if you would say ‘y’) as they require libavif.