Bug 1533878

Summary: [rfe] dnf option to display dependency resolution tree (transaction check)
Product: [Fedora] Fedora Reporter: Adam Pribyl <covex>
Component: dnfAssignee: rpm-software-management
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: carlwgeorge, kparal, packaging-team-maint, rpm-software-management, vmukhame
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:
Bug Depends On:    
Bug Blocks: 1266761, 1162409, 1213995, 1224466, 1268174, 1300669, 1304261    

Description Adam Pribyl 2018-01-12 13:03:06 UTC
Description of problem:
The yum by default was showing a dependency resolution tree like this:

Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-40.el7.centos.4 will be erased
--> Processing Dependency: httpd = 2.4.6-40.el7.centos.4 for package: httpd-manual-2.4.6-40.el7.centos.4.noarch
--> Running transaction check
---> Package httpd-manual.noarch 0:2.4.6-40.el7.centos.4 will be erased
--> Finished Dependency Resolution
Dependencies Resolved


dnf does not display anything about dependency resolution process. It was usefull when one wants to find out why certain package is e.g. brought as a dependency on update. I do not see a way how to achieve this now.

If option is not suitable, the other way that comes to my mind is something like a "print" option to a dnf shell resolvedep command. This would allow an experienced user to understand the resolution of dependencies and why certain packages are installed/erased or how to avoid it.

Comment 1 Daniel Mach 2018-01-17 12:44:14 UTC
This is quite difficult.
YUM3 did dependency resolution as a recursive dependency closure.

DNF uses libsolv, which is a SAT solver, which works differently.
It's a black-box to DNF.
However we'll check if we can't get any additional information from libsolv and display it on demand (possibly in verbose or debug mode).

Comment 2 Jaroslav Mracek 2023-08-23 06:06:10 UTC
I have a good news - there is a new feature in libsolv  that allows to answer the question why package is in transaction

run:
# `dnf install <argument> --debugsolver`
$ cd debugdata/rpms/
$ testsolv -W acpi-1.7-20.fc38.x86_64 testcase.t
installed acpi-1.7-20.fc38.x86_64@fedora:
  job install one of acpi-1.7-20.fc38.x86_64

Comment 3 Jaroslav Mracek 2023-08-23 06:21:24 UTC
*** Bug 1549851 has been marked as a duplicate of this bug. ***