Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2144202 - 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
Summary: Problem: package libknet1-compress-bzip2-plugin-1.24-3.1.el8.x86_64 requires ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: kronosnet-epel
Version: epel8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Davide Cavalca
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-19 21:33 UTC by Benedikt Steinbusch
Modified: 2022-11-27 02:19 UTC (History)
4 users (show)

Fixed In Version: kronosnet-epel-1.24-4.1.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-27 02:19:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Benedikt Steinbusch 2022-11-19 21:33:28 UTC
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:

Comment 1 Robert Scheck 2022-11-23 15:53:15 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.

Comment 2 Fedora Update System 2022-11-24 17:25:40 UTC
FEDORA-EPEL-2022-e836710b9d has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e836710b9d

Comment 3 Benedikt Steinbusch 2022-11-24 17:51:45 UTC
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 =`.

Comment 4 Davide Cavalca 2022-11-24 18:02:46 UTC
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

Comment 5 Fedora Update System 2022-11-25 01:30:02 UTC
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.

Comment 6 Robert Scheck 2022-11-25 02:31:13 UTC
Davide, why is such a strict version-release dependency using %{kronosnet_package_version} technically required? Wouldn't a more relaxed dependency work, too?

Comment 7 Fedora Update System 2022-11-27 02:19:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.