Description of problem: RHEL 9.5 has received an iptables-libs update to version iptables-libs-1.8.10-11.el9_5, but the EPEL package iptables-services-1.8.10-4.1.el9.noarch depends on the old version of iptables-libs-1.8.10-4.el9_4.x86_64. The version dependency seems unnecessary, iptables-services install couple Systemd service units, few config files and other scripts. It should work with any version of iptables and iptables-libs that might be installed on RHEL9. Version-Release number of selected component (if applicable): iptables-services-1.8.10-4.1.el9.noarch How reproducible: Steps to Reproduce: 1. Run a dnf update on RHEL9.4 server. 2. Receive an error from dnf. 3. Actual results: Error: Problem: iptables-libs-1.8.10-4.el9_4.i686 from rhel-9-for-x86_64-baseos-rpms does not belong to a distupgrade repository - package iptables-services-1.8.10-4.1.el9.noarch from @System requires (iptables-libs = 1.8.10-4.el9 or iptables-libs = 1.8.10-4.el9_4), but none of the providers can be installed - cannot install both iptables-libs-1.8.10-11.el9_5.x86_64 from rhel-9-for-x86_64-baseos-rpms and iptables-libs-1.8.10-4.el9_4.x86_64 from @System - cannot install both iptables-libs-1.8.10-11.el9_5.x86_64 from rhel-9-for-x86_64-baseos-rpms and iptables-libs-1.8.10-4.el9_4.x86_64 from rhel-9-for-x86_64-baseos-rpms - cannot install the best update candidate for package iptables-services-1.8.10-4.1.el9.noarch - cannot install the best update candidate for package iptables-libs-1.8.10-4.el9_4.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) Expected results: Additional info:
I'm getting the same error on my machines.
Me too.
Created attachment 2075733 [details] Fix iptables-epel spec file sufficient to build and require the newer iptables-libs
I am not entirely sure why the iptables-epel spec file depends on the exact version of iptables-libs being correct when all the files shipped by iptables-services are text files and have no direct interface to anything included in iptables-libs. The iptables-legacy* packages emited by the same spec file probably do have -libs dependencies but I have no idea what the purpose of those packages is. I downloaded the current SRPM using yumdownloader --source --url iptables-services then installed that, modified the spec file with the attached patch, then rpmbuild -bs iptables-epel.spec and feed the resulting SRPM into `mock -r rocky+epel-9-x86_64 --rebuild ~/rpmbuild/SRPMS/iptables-epel-1.8.10-4.1.fc40.src.rpm`. Then take the iptables-services package from /var/lib/mock/rocky+epel-9-x86_64/result and install that.
Created attachment 2075734 [details] Fix iptables-epel spec file sufficient to build and require the newer iptables-libs Bump iptables-services version number. Remove iptables-services dependency on specific iptables-libs versions so this package will no longer block future updates from RHEL. Require correct iptables-libs versions for the rest.
I'm having this issue too
It's breaking our updates and kickstart file
*** Bug 2344204 has been marked as a duplicate of this bug. ***
*** Bug 2345168 has been marked as a duplicate of this bug. ***
Sorry, been swamped since FOSDEM - I'll try and get this fixed in both epel9 and epel9-next
FEDORA-EPEL-2025-e92117a6e9 (iptables-epel-1.8.10-11.1.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-e92117a6e9
verified that the linked packages resolved the problem in a test system, thanks!
FEDORA-EPEL-2025-e92117a6e9 has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-e92117a6e9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2025-e92117a6e9 (iptables-epel-1.8.10-11.1.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
Hi all. This seem to be fixed for some cases but is bound to break again. Can Trevor Hemsley's patch be applied to the package specs? This package really does not need strict package version dependencies as it does not rely on any specific API/ABI, just a standard iptables command line interface. We still have the issue while installing this package in some specific circumstances. For example, while building VM templates for RHEL (in automated way), we exclusively rely on packages available on ISO media. We don't want to unnecessarily temporarily subscribe such systems to RHMS just to pull some packages. The situation, as it is now, is that ISO media for RHEL 9.5 has older version of iptables-libs and thus the latest version of iptables-services cannot be installed. This will once again "unbreak" with RHEL 9.6 but is bound to break again after that. So we are constantly stuck in chicken-egg problem. Relaxing iptables-services package requirements should solve this for a foreseeable future as Trevor Hemsley already noted.
(In reply to Bojan Vitnik from comment #15) > Hi all. This seem to be fixed for some cases but is bound to break again. > Can Trevor Hemsley's patch be applied to the package specs? This package > really does not need strict package version dependencies as it does not rely > on any specific API/ABI, just a standard iptables command line interface. +1 This has already happened more than once in the past.
I opened BZ#2349297 to argue that the `iptables-services` package should either be renamed to `iptables-legacy-services`, or removed entirely.