Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I actually run into this on openSUSE MicroOS Desktop (snapshot 20210427), as it is switching to using MicroDNF and DNF through PackageKit for software management (see also https://bugzilla.redhat.com/show_bug.cgi?id=1946024 ). In MicroOS, we would like to ignore RPM's weak dependencies. The situation is, however, like this: - if I install packages RPM with zypper (by means of transactional-update or tukit), weak dependencies are *not* installed, which is the correct behavior (kind of out of scope here, but just for reference) - if I install microdnf and install packages with it, weak dependencies are *not* installed, which is the correct behavior - if I install packages with pkcon, weak dependencies *are* installed, which is not what we want. To prevent weak dependencies to be installed, we have "install_weak_deps=False" in /etc/dnf/dnf.conf. And this seems to be enough for microdnf to do the right thing. However, it seems like it is being ignored by pkcon (which in turns led us to believe that it is in fact ignored by libdnf). Version-Release number of selected component (if applicable): $ rpm -qa {PackageKit,microdnf} PackageKit-1.2.2-10.2.x86_64 microdnf-3.8.0-1.1.x86_64 How reproducible: 100% Steps to Reproduce: just `pkcon install <package>`, and you'll see that recommended packages are also being installed. E.g., `pkconf install system-config-printer` (compared to `microdnf install system-config-printer`) Actual results: $ pkcon install system-config-printer The following packages have to be installed: system-config-printer-1.5.15-1.1.x86_64 A printer administration tool system-config-printer-applet-1.5.15-1.1.noarch Notification icon for printing via system-config-printer system-config-printer-dbus-service-1.5.15-1.1.noarch D-Bus service to configure printing via system-config-printer $ sudo microdnf install system-config-printer Installing: system-config-printer-1.5.15-1.1.x86_64 repo-oss 103.0\u00a0kB Transaction Summary: Installing: 1 packages Reinstalling: 0 packages Upgrading: 0 packages Obsoleting: 0 packages Removing: 0 packages Downgrading: 0 package Expected results: That pkcon and microdnf behave the same (where the wanted behavior, in this case, is the microdnf one, i.e., no recommended packages).
Since this is working fine in microdnf (and libdnf), I suppose this will require some changes on PackageKit end.
It works in microdnf because there's explicit code forcing it disabled. Should we not have this in the context setup instead of making each consumer manually set things up to handle it? If we want to make PackageKit do the handling, then sure, we can add it there. If we want this respected at the libdnf level, then we should fix this in libdnf.
To elucidate, the reason why it works in microdnf is because of this code block: https://github.com/rpm-software-management/microdnf/blob/7b84c0699311839ea79b0cfbcbf88ef91e3c0ce1/dnf/plugins/install/dnf-command-install.c#L81-L82 This doesn't exist in PackageKit. But I think we probably want to add this to dnf_context_setup_sack_with_flags() in libdnf like we did for the sticky vendors feature.
BTW, I don't know if it's still interesting to "fix" this at the libdnf level but in the meantime *I think* I've figured out a way to deal with it at the PackageKit level. See https://github.com/PackageKit/PackageKit/pull/488 I think it's actually fine. In fact, as far as I understand, the dnf_transaction_set_dont_solve_goal() API is there exactly for dealing with cases like this, isn't it?
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.