RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2005305 - dnf should not pull (already unmet) weak dependencies on updates
Summary: dnf should not pull (already unmet) weak dependencies on updates
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: dnf
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jaroslav Mracek
QA Contact: Eva Mrakova
Mariya Pershina
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-09-17 11:22 UTC by Jan Pazdziora
Modified: 2022-05-27 12:23 UTC (History)
8 users (show)

Fixed In Version: dnf-4.10.0-1.el9
Doc Type: Enhancement
Doc Text:
.New DNF options `exclude_from_weak_autodetect` and `exclude_from_weak` With this enhancement, the default DNF behavior does not install unwanted weak dependencies. To modify this behavior, use the following new options: * `exclude_from_weak_autodetect` + If enabled, the `exclude_from_weak_autodetect` option autodetects unmet weak dependencies (Recommends: or Supplements:) of packages installed on your system. As a result, providers of these weak dependencies are not installed as weak dependencies, but, if pulled in, they are installed as regular dependencies. The default value is `true`. * `exclude_from_weak` + If enabled, the `exclude_from_weak` option prevents installing packages as weak dependencies (Recommends: or Supplements:). You can specify packages either by a package name or a glob, and separate them by a comma. The default value is `[]`.
Clone Of:
Environment:
Last Closed: 2022-05-17 15:55:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:
emrakova: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-97446 0 None None None 2021-09-17 11:26:04 UTC
Red Hat Product Errata RHBA-2022:3957 0 None None None 2022-05-17 15:55:12 UTC

Description Jan Pazdziora 2021-09-17 11:22:24 UTC 
Description of problem:

The weak rpm dependencies like Recommends make it possible for maintainers to list additional requirements that the software strictly speaking does not need for its correct operation (even if missing them might lead to some feature not being available). It is therefore OK for admins or authors of container images or hardened kickstarts to exclude some of the weakly-recommended packages to avoid the package bloat they don't need or to prevent security exposure by having software installed that is not needed. Admins might also just run the initial installation with install_weak_deps=false option for dnf or %packages --excludeWeakdeps in kickstart for anaconda; or they may install the full package set with weak dependencies, and the remove those packages (and their now unneeded dependencies) they do not need.

The problem is that during dnf update / upgrade operation, those weak dependencies will pull the Recommended packages back into the transaction, rendering the work that went into minimizing or hardening the setup  lost.

During upgrade, if there was a weak dependency in the old package version and it was not met, the same weak dependency should not be added to the transaction.

New weak dependencies in the new package versions are OK to be added to the transations (unless of course disabled via install_weak_deps=false).

Version-Release number of selected component (if applicable):

dnf-4.7.0-2.el9.noarch

How reproducible:

Deterministic.

Steps to Reproduce:
1. Install crontabs package, older than the one which is in the currently enabled repository:
   dnf install -y crontabs-1.11-25.20190603git.el9.noarch.rpm
2. Ensure cronie package (which is Recommended) is not installed:
   dnf remove -y cronie
3. Now update crontabs:
   dnf upgrade -y crontabs

Actual results:

Dependencies resolved.
================================================================================
 Package           Arch      Version                     Repository        Size
================================================================================
Upgrading:
 crontabs          noarch    1.11-26.20190603git.el9     beaker-BaseOS     19 k
Installing dependencies:
 cronie-anacron    x86_64    1.5.7-5.el9                 beaker-BaseOS     33 k
Installing weak dependencies:
 cronie            x86_64    1.5.7-5.el9                 beaker-BaseOS    116 k

Expected results:

Only crontags upgraded, cronie (and cronie-anacron) not pulled in back to the system.

Additional info:

This is a RHEL 9 bugzilla for a Fedora bug 1699672 which saw a lot of discussions about the intended implementation. Here I tried to focus on the high-level expected behaviour.
Comment 1 Jaroslav Mracek 2021-09-17 13:10:26 UTC 
I created PR with a solution: https://github.com/rpm-software-management/dnf/pull/1780, https://github.com/rpm-software-management/libdnf/pull/1279, https://github.com/openSUSE/libsolv/pull/454

Tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/1005
Comment 7 Jan Pazdziora 2022-02-04 13:01:58 UTC 
This bugzilla focused on updates / upgrades transactions where the "already unmet" dependencies could be observed.

If the implemented change also modified the behaviour on installations of previously uninstalled packages, some more tuning to the implementation might be needed to really only kick in for packages being updated.
Comment 10 Jaroslav Mracek 2022-02-07 10:51:27 UTC 
I am really sorry but I provided possibilities incorrectly. Please ignore comment 6 and comment 9.

(In reply to Jan Pazdziora from comment #7)
> This bugzilla focused on updates / upgrades transactions where the "already
> unmet" dependencies could be observed.

Firs of all I need to clarify that the feature cannot be implemented only on upgrades - It cannot be achieved for two technical reason - 
1. DNF creates one transaction for all operations (install, upgrades are performed together).
2.a Install operation or commands (not only install) also triggers update. (example - I have already installed foo-1-1.noarch. Then I will install bar-2-2.noarch that requires foo-2. It means the install command will trigger upgrade that dnf cannot detect in advance. And if foo recommends something, it will be installed)
2.b Install operation with --best (default in RHEL) triggers always upgrade when package is already installed but in lower version.

> If the implemented change also modified the behaviour on installations of
> previously uninstalled packages, some more tuning to the implementation
> might be needed to really only kick in for packages being updated.

Please could you provide your opinion for following options. I really afraid that we have not many other options (we are limited by a schedule and resources).

1. Keep it like it is
2. Disable autodetection
3. Start to ignore rich dependencies for autodetection of unmet weak dependencies. (may be we will be unable to deliver for GA)
We have a problem to detect rich dependencies correctly in autodetections because we do not know whether their conditions were met or not in past.

4. In theory the auto-detection can be only triggered by upgrade command but it will create an inconsistency in DNF behavior when upgrade operation is triggered by the another command (install, buildeps, downgrade, ...) - not preferable, see above (not for GA).

Which options are preferable?
Comment 11 Jan Pazdziora 2022-02-13 13:32:22 UTC 
I'm afraid I'm not savvy enough in the internals of dnf and its libraries and what is possible and what not, to pick from the options.

One thing I'd like to clarify is the use case though. When I talk about update / upgrade operation, I don't have the specific "dnf update" / "dnf upgrade" command in mind necessarily, I talk about update / upgrade of specific packages. The example you gave, "dnf install bar-2-2.noarch" which forces upgrade of foo package, would be a nice case. If bar itself has some weak dependencies, they should be pulled in, it's an installation of a new package. If foo-2 has a weak dependency that foo-1-1 also had, and that dependency was not met, when the transaction started, I'd expect that weak dependency not to get pulled in. If foo-2 has a new weak dependency that foo-1-1 did not have, I'd expect that weak dependency to get pulled in. (All these assume install_weak_deps=True, of course.)

So in one dnf transaction, you might have a mixture of cases -- some of them installations of new packages, some of them new weak dependencies for packages being upgraded (so those dependencies couldn't have been unmet because they did not exist), and then the specific case of weak dependencies that were present in older version of packages being upgrades, and were not met.

Do we agree that it is a useful feature to have, irrespectively what the software can to today?

If yes, the implementation in RHEL 9.0 should ideally be such which gets us furthermost towards this behaviour, even if in 9.0 it's not going to be exactly this behaviour. That should be the guiding principle for chosing one of the four (or some other) approach in 9.0.
Comment 13 errata-xmlrpc 2022-05-17 15:55:05 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: dnf), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3957
Note You need to log in before you can comment on or make changes to this bug.