Bug 1149001

Created attachment 943578 [details]
The contents of the debugdata directory after the dnf command is run.

Sometimes dnf and yum can't find a way to solve the dependencies in a transaction and fails.  This can happen because a system contains packages not from the base distribution, like packages from other releases or packages from other sources than Fedora.  On such a failure, dnf does not provide the dependency resolution information needed to resolve the problem.

As an example, here is the output from an attempt to update using the F21 version of dnf.  The repository "test" points to the F21 alpha release, while the regular repositories still point to F20.


mimmi$ sudo env LANG=en_US.utf8 dnf -v --debugsolver --best --disablerepo=\* --enablerepo=test upgrade octave
cachedir: /var/cache/dnf/x86_64/20
DNF version: 0.6.1
repo: using cache for: test
not found deltainfo for: Fedora test 21 - x86_64
not found updateinfo for: Fedora test 21 - x86_64
--> Starting dependency resolution
--> Finished dependency resolution
Error: package MegaMek-0.30.11-7.fc15.x86_64 requires libgcj_bc.so.1()(64bit), but none of the providers can be installed


This output doesn't help me in understanding what the MegaMek and libgcj_bc.so.1 have to do with octave.  The contents of debugdata doesn't help in any obvious way either.

The set of packages on the machine is mixed, as you see from the F15 version of MegaMek for example.  It's not surprising that dnf can not do the upgrade.  But the problem is that it doesn't give me enough information to understand why and decide how to resolve it.  With yum, I could study the "Processing Dependency" messages, and figure out what was going on.  Attempting to do an installation using yum instead and see what it says is my best workaround for the moment.

In https://rpm-software-management.github.io/dnf/cli_vs_yum.html#dependency-processing-details-are-not-shown-in-the-cli there is an argument that the output about processing dependencies gets quite confusing, especially in big transactions.  I do agree with that, and I'm not saying this information should be printed by default.  The less verbose behavior of dnf is preferable.  But sometimes such information is needed, and then I would like to have some option or similar to enable it.

Finally, just to be completely clear: this bugzilla is not about why the upgrade fails.  This bugzilla is about how to get information from dnf needed to figure out why the upgrade fails.

Package versions:
dnf-0.6.1-1.fc21.noarch
hawkey-0.5.1-1.fc21.x86_64
libsolv-0.6.4-3.fc21.x86_64