Bug 1896489
| Summary: | DNF transaction resolution is silent, leaving the path from the input action to resulting flat list impossible to follow | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Kyle Walker <kwalker> |
| Component: | libdnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | swm-qe |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.3 | CC: | cbesson, jcastran, pstodulk, rmetrich |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | 8.0 | ||
| 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: | 2023-08-09 12:48:39 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: | |||
In future version of libdnf I prepare a different output: ./microdnf remove python3-dnf Problem 1: The operation would result in removing the following protected packages: dnf Problem 2: package dnf-4.7.0-1.git.9385.8f47765.fc33.noarch requires python3-dnf = 4.7.0-1.git.9385.8f47765.fc33, but none of the providers can be installed - conflicting requests - problem with installed package ./microdnf remove kernel-core Problem: The operation would result in removing of running kernel: kernel-core-0:5.10.21-200.fc33.x86_64 Is it what do you expect? That helps, but would only account for the second issue listed above. The difficulty is that both of those are just manifestations of the same problem. I really can't tell without looking at a bunch of specfiles, and having a tonne of knowledge about dependency resolution (with a healthy dose of libdnf insight to boot) to figure out what is causing packages to be connected to one another.
I would say that this particular "silent dependency resolution" problem is also the underlying issue that results in the following (which came to my attention just a moment ago):
1957280 – DNF with versionlock silences a conflict due to a provide
I guess I am trying to get to the point that I can get a similar level of insight into a transaction as the content-resolver initiative provides:
https://github.com/minimization/content-resolver
With the exception to the above being that I don't want it for the entire compose. I am looking to increase the verbosity of dnf/libdnf/libsolv to the degree that I can get similar insight at transaction time.
@Jaroslav,
Is there any way we can have a mode in libdnf/libsolv that essentially goes through the dependency resolution process on a per-package basis?
- [A]: Requires [B]
- [B]: Requires [C]
Where the resolver would spew something like:
$ yum install a
> Including [A]
Transaction: [A]
> [A] Requires [B] (Including)
Transaction: [A] + [B]
> [B] Requires [C] (Including)
Result: [A] + [B] + [C]
This would get horrendously verbose for larger transactions, but would give us the needed information to try and unravel what is happening and why.
*** Bug 1840196 has been marked as a duplicate of this bug. *** I have a great news - testsolv add a new option (-W) to enhance debugging. The backport of the feature was already requested - Bug 2174869 - [RFE] requesting the -W flag for testsolv which can be seen in upstream testsolv How to use it? 1. create testsolv data for transaction that you want to investigate # dnf install dnf --installroot=$(pwd) --releasever=/ --debugsolver 2. Run testsolv -W <SPEC> testcase.t. I recommend to limit spec as possible - use whole NEVRA is the best. The report make sence if you read it from the last record to the beginning. $ testsolv -W memstrack-0.2.4-2.fc36.x86_64 testcase.t installed dnf-4.15.0-20230421005315.2.ga798d23e.fc36.noarch@copr:copr.fedorainfracloud.org:rpmsoftwaremanagement:dnf-nightly: job install one of dnf-4.15.0-20230408005110.0.g5306910d.fc36.noarch, dnf-4.15.0-20230409005453.0.g5306910d.fc36.noarch, dnf-4.15.0-20230410005323.0.g5306910d.fc36.noarch, dnf-4.15.0-20230411005348.0.g5306910d.fc36.noarch, dnf-4.15.0-20230412005334.0.g5306910d.fc36.noarch, dnf-4.15.0-20230413005207.0.g5306910d.fc36.noarch, dnf-4.15.0-20230415005513.0.g5306910d.fc36.noarch, dnf-4.15.0-20230416005540.0.g5306910d.fc36.noarch, dnf-4.15.0-20230417005444.0.g5306910d.fc36.noarch, dnf-4.15.0-20230418005238.1.gde9c5c5b.fc36.noarch, dnf-4.15.0-20230419005455.1.gde9c5c5b.fc36.noarch, dnf-4.15.0-20230420005325.1.gde9c5c5b.fc36.noarch, dnf-4.15.0-20230421005315.2.ga798d23e.fc36.noarch, dnf-4.11.1-2.fc36.noarch, dnf-4.14.0-1.fc36.noarch, dnf-4.2.7-7.el8_1.noarch installed python3-dnf-4.15.0-20230421005315.2.ga798d23e.fc36.noarch@copr:copr.fedorainfracloud.org:rpmsoftwaremanagement:dnf-nightly: dnf-4.15.0-20230421005315.2.ga798d23e.fc36.noarch requires python3-dnf = 4.15.0-20230421005315.2.ga798d23e.fc36 installed python3-rpm-4.17.1-3.fc36.x86_64@updates: python3-dnf-4.15.0-20230421005315.2.ga798d23e.fc36.noarch requires python3-rpm >= 4.14.0 installed rpm-sign-libs-4.17.1-3.fc36.x86_64@updates: python3-rpm-4.17.1-3.fc36.x86_64 requires librpmsign.so.9()(64bit) installed openssl-libs-1:3.0.8-1.fc36.x86_64@updates: rpm-sign-libs-4.17.1-3.fc36.x86_64 requires libcrypto.so.3()(64bit) installed crypto-policies-20220428-1.gitdfb10ea.fc36.noarch@updates: openssl-libs-1:3.0.8-1.fc36.x86_64 requires crypto-policies >= 20180730 installed crypto-policies-scripts-20220428-1.gitdfb10ea.fc36.noarch@updates: crypto-policies-20220428-1.gitdfb10ea.fc36.noarch recommends crypto-policies-scripts installed grubby-8.40-67.fc36.x86_64@updates: crypto-policies-scripts-20220428-1.gitdfb10ea.fc36.noarch recommends grubby installed grub2-tools-1:2.06-62.fc36.x86_64@updates: grubby-8.40-67.fc36.x86_64 requires grub2-tools installed dracut-057-3.fc36.x86_64@updates: grub2-tools-1:2.06-62.fc36.x86_64 requires dracut installed memstrack-0.2.4-2.fc36.x86_64@fedora: dracut-057-3.fc36.x86_64 recommends memstrack Hi Jardo, that's a great new! The mentioned bz is for RHEL 9. Is it expected the feature to be backported to RHEL 8 also? (In reply to Petr Stodulka from comment #11) > Hi Jardo, that's a great new! The mentioned bz is for RHEL 9. Is it expected > the feature to be backported to RHEL 8 also? I am so sorry, the new option would require a rebase of libsolv, therefore it is not recommended for RHEL 8.9 or later. Therefore we have no plan to release it to RHEL8. I am proposing to close it, because there is an alternative solution provided by Bug 2174869 - [RFE] requesting the -W flag for testsolv which can be seen in upstream testsolv. I know that this not a perfect solution. What do you think? Yep, it makes sense to not rebase libsolv in RHEL 8 (we can always use the RHEL 9 functionality to debug RHEL 8 issues). I would also say that the -W flag functionality solves this particular need since libsolv-tools is now in CRB. Thank you! It looks like that solution `testsolv -W` in RHEL9 is sufficient therefore closing the bug as a duplicate of Bug 2174869. *** This bug has been marked as a duplicate of bug 2174869 *** |
Description of problem: Per the subject, the DNF transaction resolution operation is completely silent. In the event that you need to determine how a package was brought into a transaction, you cannot do so based off of only the DNF output itself. This is problematic in more than a few use-cases, however, the following are immediately issues: Issue 1: Unable to determine what is causing packageC to be pulled in. Action: packageA-1: Requires packageB-1 packageB-1: Requires packageC-1 Command: # yum install packageA Results: Installing: packageA x86_64 1.0-1.el8 test 6.4 k Installing dependencies: packageB x86_64 1.0-1.el8 test 6.4 k packageC x86_64 1.0-1.el8 test 6.4 k Issue 2: Due to no dependency evaluation output, removal of a package which depends indirectly on a protected package leaves an indiscernible failure. Action: packageA-1: Requires packageB-1 packageB-1: Requires packageC-1 Command: # yum install packageA Results: # yum remove packageA --disablerepo=\* --repofrompath test,file:///root/repo/ --nogpgcheck --setopt protected_packages=packageC Updating Subscription Management repositories. Unable to read consumer identity This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Added test repo from file:///root/repo/ Error: Problem: The operation would result in removing the following protected packages: packageC (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Version-Release number of selected component (if applicable): libdnf-0.48.0-5.el8 How reproducible: Easily Additional info: The use of the --debugsolver flag generates some data, but really doesn't provide the functionality desired in it's current implementation. For example, for the first issue above, you get the following: # cat rpms/solver.result install packageA-1.0-1.el8.x86_64@test install packageB-1.0-1.el8.x86_64@test install packageC-1.0-1.el8.x86_64@test # cat rpms/testcase.t repo @System -99.-1000 testtags @System.repo.gz repo test -99.-1000 testtags test.repo.gz system x86_64 rpm @System poolflags implicitobsoleteusescolors whatprovideswithdisabled solverflags allowdowngrade allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes job install oneof packageA-1.0-1.el8.x86_64@test [forcebest,setevr,setarch] job multiversion provides kernel job multiversion provides kernel-PAE job multiversion provides installonlypkg(kernel) job multiversion provides installonlypkg(kernel-module) job multiversion provides installonlypkg(vm) job multiversion provides multiversion(kernel) result transaction,problems solver.result This gives you the input, and the output of the operation, but not the individual steps. Theoretically, you could use the libsolv-tools testsolv utility to emit the information: # testsolv -vvv rpms/testcase.t <snip> propagate decision 636: packageA-1.0-1.el8.x86_64 [636] Install.level1 unit Rule #2: !packageA-1.0-1.el8.x86_64 [636] (w1) Install.level1 packageB-1.0-1.el8.x86_64 [637] (w2) next rules: 0 0 -> decided to install packageB-1.0-1.el8.x86_64 propagate decision 637: packageB-1.0-1.el8.x86_64 [637] Install.level1 unit Rule #1: !packageB-1.0-1.el8.x86_64 [637] (w1) Install.level1 packageC-1.0-1.el8.x86_64 [638] (w2) next rules: 0 0 -> decided to install packageC-1.0-1.el8.x86_64 propagate decision 638: packageC-1.0-1.el8.x86_64 [638] Install.level1 ----- propagate end ----- resolving job rules resolving installed packages deciding unresolved rules installing recommended packages deciding orphaned packages solver statistics: 0 learned rules, 0 unsolvable, 0 minimization steps done solving. solver took 5 ms final solver statistics: 0 problems, 0 learned rules, 0 unsolvable solver_solve took 8 ms Even the above requires a fairly high level of understanding and insight to glean that the dependency tree is packageA -> packageB -> packageC in the above. The DNF/libdnf side should give (when prompted) enough information to be able to determine the source dependency and cause of various packages being pulled into the transaction.