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 1896489 - DNF transaction resolution is silent, leaving the path from the input action to resulting flat list impossible to follow
Summary: DNF transaction resolution is silent, leaving the path from the input action ...
Keywords:
Status: CLOSED DUPLICATE of bug 2174869
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libdnf
Version: 8.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 8.0
Assignee: Packaging Maintenance Team
QA Contact: swm-qe
URL:
Whiteboard:
: 1840196 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-10 17:17 UTC by Kyle Walker
Modified: 2024-03-25 17:00 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-09 12:48:39 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Kyle Walker 2020-11-10 17:17:59 UTC 
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.
Comment 2 Jaroslav Mracek 2021-03-18 12:40:00 UTC 
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?
Comment 4 Kyle Walker 2021-05-05 14:59:20 UTC 
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.
Comment 6 Kyle Walker 2021-09-22 18:35:33 UTC 
*** Bug 1840196 has been marked as a duplicate of this bug. ***
Comment 10 Jaroslav Mracek 2023-04-21 06:18:25 UTC 
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
Comment 11 Petr Stodulka 2023-04-21 08:27:10 UTC 
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?
Comment 12 Jaroslav Mracek 2023-04-24 11:12:59 UTC 
(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.
Comment 13 Jaroslav Mracek 2023-05-22 08:29:45 UTC 
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?
Comment 14 Kyle Walker 2023-08-09 12:46:50 UTC 
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!
Comment 15 Jaroslav Mracek 2023-08-09 12:48:39 UTC 
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 ***
Note You need to log in before you can comment on or make changes to this bug.