Description of problem: With the release of EL8.7, the EL repositories now have libknet1-1.24-2.el8.x86_64, but EPEL8 has libknet1-compress-bzip2-plugin-1.24-3.1.el8.x86_64 with a dependency on libknet1(x86-64) = 1.22-2.el8_6 Version-Release number of selected component (if applicable): 1.24-3.1 How reproducible: Always Steps to Reproduce: 1. Have libknet1-compress-bzip2-plugin-1.24-3.1.el8.x86_64 installed 2. run dnf upgrade Actual results: Depsolve Error occurred: Problem: package libknet1-compress-bzip2-plugin-1.24-3.1.el8.x86_64 requires libknet1(x86-64) = 1.22-2.el8_6, but none of the providers can be installed - cannot install both libknet1-1.24-2.el8.x86_64 and libknet1-1.22-2.el8_6.x86_64 - cannot install the best update candidate for package libknet1-compress-bzip2-plugin-1.24-3.1.el8.x86_64 - cannot install the best update candidate for package libknet1-1.22-2.el8_6.x86_64 Expected results: Update packages without error Additional info:
We are experiencing the same issue here, got pointed out by GSS/CEE that this is caused by the EPEL 8 packages of libknet1. We used the following steps to workaround the update to RHEL 8.7 (maybe it helps somebody else): dnf update --exclude="libknet1*" # Update to RHEL 8.7 (except libknet1) dnf downgrade "libknet1-*" --disablerepo=epel # Switch libknet1 from EPEL to RHEL dnf update --disablerepo=epel # Finally update libknet1 from RHEL 8.7 The correct solution however are indeed fixed libknet1 packages in EPEL 8.
FEDORA-EPEL-2022-e836710b9d has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e836710b9d
I do not want to be rude, but can I ask why these packages are in EPEL 8 when the EL 8 HighAvailability repositories have packages of the plugins matching version and release of the libknet1 package in PowerTools? These packages in EPEL have broken updates for us the last three times the version of `libknet1` was bumped. We are now working around this by ignoring these packages in EPEL via `exclude =`.
This is in EPEL to provide unshipped packages that are required for other packages in EPEL 8 (notably asterisk and its dependencies). EPEL cannot make use of HighAvailability, and packages in HighAvailability and other channels are eligible for addition in EPEL. See https://bugzilla.redhat.com/show_bug.cgi?id=2121785 for the original discussion around this. I agree that the current situation is suboptimal, this is a side effect of the branching setup we have in place for EPEL 8 (and EPEL 9, fwiw). The good news is that a proposal is being discussed that should make this a lot better for EPEL 10 and prevent this kind of breakage down the road: https://discussion.fedoraproject.org/t/epel-10-proposal/44304/9
FEDORA-EPEL-2022-e836710b9d has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e836710b9d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Davide, why is such a strict version-release dependency using %{kronosnet_package_version} technically required? Wouldn't a more relaxed dependency work, too?
FEDORA-EPEL-2022-e836710b9d has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.