-
Bug
-
Resolution: Unresolved
-
Normal
-
rhel-8.10, rhel-9.4, rhel-10.0.beta
-
dnf-4.20.0-2.el10
-
None
-
None
-
sst_cs_software_management
-
ssg_core_services
-
16
-
19
-
None
-
False
-
-
No
-
None
-
-
Pass
-
Automated
-
Bug Fix
-
-
Proposed
-
None
On RHEL 7 one can do e.g. "yum remove 'nfs' 'sss'" to remove NFS and SSSD related packages from a set of systems. Doing this from the command line or with Ansible automation using the yum module works the same.
On RHEL 8/9 "dnf remove 'nfs'" or "dnf remove 'sss'" works like the above only if there are such named packages present. On the second invocation dnf falls back to fileprovides and tries to remove kernel-core which luckily fails due to it being a protected package. Using the Ansible yum module on RHEL 8/9 uses dnf as a backend so it does the same.
The workaround would be to use 'nfs*' 'lib*nfs*' or 'sss*' 'lib*sss*' instead. However this is different from yum, a bit clumsy, and a mistake in typing might make dnf fallback to fileprovides and if it finds only unprotected packages then the result could be very much unexpected.
It should be considered that dnf would be changed to behave like yum in this regard.
Wrt this change it could be argued that it's good that "dnf install 'foo'" and "dnf remove 'foo'" work symmetrically. However, as explained above, dnf remove behavior is currently inconsistent with itself (sometimes considers fileprovides, sometimes not) and in general installing new packages should not cause issues whereas removing unexpected packages might render the system or at least applications not working as they should.
Thanks.
- is cloned by
-
RHEL-38470 dnf removes packages when yum would not
- Closed
- links to
-
RHBA-2024:132912 DNF stack bug fix and enhancement update