Bug 2144202
| Summary: | 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 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Benedikt Steinbusch <b.steinbusch> |
| Component: | kronosnet-epel | Assignee: | Davide Cavalca <davide> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel8 | CC: | carl, davide, redhat-bugzilla, robert.scheck |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | kronosnet-epel-1.24-4.1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-27 02:19:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Benedikt Steinbusch
2022-11-19 21:33:28 UTC
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. |