To reproduce: 1. Install a clean minimal Fedora 41 2. Observe that /usr/sbin/iptables and /usr/sbin/ip6tables exist 3. Upgrade to Fedora 42 with iptables-nft-1.8.11-8.fc42 4. Observe that no iptables or ip6tables exists anywhere in the path 5. Run 'dnf reinstall iptables-nft' 6. Observe that there is now a /usr/sbin/iptables CCing Zbyszek as this is no doubt to do with sbin merge...
So yes, I can indeed reproduce this. After upgrading to f42 via 'dnf system-upgrade --releasever 42 download && dnf offline reboot', there is iptables-nft-1.8.11-8.fc42.x86_64 installed. 'alternatives --list' shows: man manual /usr/bin/man.man-db ld auto /usr/bin/ld.bfd ebtables auto /usr/sbin/ebtables-nft iptables auto /usr/sbin/iptables-nft soelim manual /usr/bin/soelim.groff arptables auto /usr/sbin/arptables-nft libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so The non-nft-suffixed symlinks are indeed missing from /usr/bin. Trying to repeat what rpm should have done: # pfx=/usr/bin/iptables # pfx6=/usr/bin/ip6tables # update-alternatives --install \ $pfx iptables $pfx-nft 10 \ --follower $pfx6 ip6tables $pfx6-nft \ --follower $pfx-restore iptables-restore $pfx-nft-restore \ --follower $pfx-save iptables-save $pfx-nft-save \ --follower $pfx6-restore ip6tables-restore $pfx6-nft-restore \ --follower $pfx6-save ip6tables-save $pfx6-nft-save # alternatives --list man manual /usr/bin/man.man-db ld auto /usr/bin/ld.bfd ebtables auto /usr/sbin/ebtables-nft iptables auto /usr/bin/iptables-nft soelim manual /usr/bin/soelim.groff arptables auto /usr/sbin/arptables-nft libnssckbi.so.x86_64 auto /usr/lib64/pkcs11/p11-kit-trust.so cifs-idmap-plugin auto /usr/lib64/cifs-utils/cifs_idmap_sss.so The symlinks exist now. So I wonder, does %post task not run during the update? Or does it run before sbin and bin are actually merged? With sbin a symlink, things seem OK: At least 'dnf downgrade iptables-nft && dnf update iptables-nft' on that f42 system is fine and the symlinks exist afterwards. No idea what iptables package could do differently or what makes it a special case (other packages seem to survive the f41->f42 upgrade at least).