Bug 2005305

Summary:	dnf should not pull (already unmet) weak dependencies on updates
Product:	Red Hat Enterprise Linux 9	Reporter:	Jan Pazdziora (Red Hat) <jpazdziora>
Component:	dnf	Assignee:	Jaroslav Mracek <jmracek>
Status:	CLOSED ERRATA	QA Contact:	Eva Mrakova <emrakova>
Severity:	unspecified	Docs Contact:	Mariya Pershina <mpershin>
Priority:	unspecified
Version:	9.0	CC:	emrakova, james.antill, jpazdziora, mpershin, pasik, petersen, pkratoch, tbajer
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	emrakova: needinfo-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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 `[]`.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 15:55:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Pazdziora (Red Hat) 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 (Red Hat) 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 (Red Hat) 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