Description of problem: RHEL 9 Content Structure and Guidelines state that weak dependencies in BaseOS are allowed, but discouraged. By using the Recommends weak dependencies especially for packages in @core group (Minimal host installation) or their direct dependencies, the recommended package gets pulled into the installed package set depending on the current configuration of the dnf transaction. The python3-libs package Recommends (python3-tkinter(x86-64) = 3.9.2-1.el9 if tk(x86-64)) and python3(x86-64) = 3.9.2-1.el9. If those are needed by python3-libs for correct operation (the first one when tk is also installed), Requires should be used. If they are essential in minimal host installations (or minimal host installations with tk), they should be listed in the @core group in the comps file, not pulled in as a weak side-effect of having python3-libs in @core. If they are listed primarily for convenience, Suggests might be better option. Or just drop the weak dependency completely. Note: the python3-libs itself gets installed in minimal host installation (@core) via dnf and python3-dnf and python3 dependency. Version-Release number of selected component (if applicable): python3-libs-3.9.2-1.el9.x86_64 How reproducible: Deterministic. Steps to Reproduce: 1. rpm -q --recommends python3-libs Actual results: (python3-tkinter(x86-64) = 3.9.2-1.el9 if tk(x86-64)) python3(x86-64) = 3.9.2-1.el9 Expected results: No output. Additional info:
I don't think this is much of an issue, unless tk (and the graphical stack it requires) is also in minimal systems.
(that comment was for tkinter; as for the other dependency, python3 is already in @core)
This issue does bring up the question of why we have the python3/python3-libs split anyway, and if it wouldn't be better to carve things differently. For example, I could see moving /usr/bin/python3.9 into (what is now) -libs, on the grounds that `sys.executable` is generally assumed to be available.
For tkinter, I agree that having it as a rich dependency makes less of a problem of unexpected package slipping into some limited installation. Still, is there a reason to have this as a Recommends and not Requires?
> Still, is there a reason to have this as a Recommends and not Requires? Yes, the reason is that when it is Recommends, users (=admins in this context) of the system can uninstall it. When it is Requires, they generally cannot (unless they also remove tk or force rpm to do the removal despite broken deps).
The problem of the intended ability of uninstalling those Recommended packages (to minimize or harden installations) is that with current dnf implementation, they will be installed right back during the first update of the python3-libs package. That is, unless install_weak_deps=False is set, which however is not the configuration which is tested across the board.
IMHO Recommends with the funny behavior (i.e. bz1699672) is still better than Requires because it allow uninstalling. I see two options: Option 1 -- Requires: tkinter is always installed with Python and tk, if you don't want it, you have no options other than removing Python or tk. Option 2 -- Recommends: tkinter is installed with Python and tk unless you opt-out. If you don't want it, you have options: You can exclude tkinter, you can uninstall tkinter, you can set install_weak_deps=False. Does it creeps back on every upgrade of Python? Yes. But you can still exclude it, uninstall it or use install_weak_deps=False. Worst case scenario? Tou have tkinter installed even if you don't want to, which is no worse than option 1 (because it is option 1, with available revert mechanism). As a side note, many environments don't even bother with `yum update` because they are created, used and thrown away (e.g. containers), however I realize this is most likely moot because containers won't usually have tk installed.
Recommends: (python3-tkinter(x86-64) = 3.9.2-1.el9 if tk(x86-64)) IMO, The rich dependency here is OK. It does not affect minimal systems. Recommends: python3(x86-64) = 3.9.2-1.el9. The python3 / python3-libs split is weird, due to some historical reasons. In practice, you'll always have both installed (or none of them). We will revisit this in Fedora, but I don't think it's wise to rock the boat in RHEL 9 at this point.
> Recommends: python3(x86-64) = 3.9.2-1.el9. > > The python3 / python3-libs split is weird, due to some historical reasons. > In practice, you'll always have both installed (or none of them). > We will revisit this in Fedora, but I don't think it's wise to rock the boat > in RHEL 9 at this point. Indeed. To clarify, this will also not affect minimal systems. If the minimal system uses microdnf, python3-libs will not be installed (and thus won't pull in python3 on update). And if the minimal system still has dnf, both python3 and python3-libs will already be installed.
*** Bug 2093821 has been marked as a duplicate of this bug. ***
*** Bug 2162261 has been marked as a duplicate of this bug. ***