Bug 994011 - Unhelpful error message when faced with unresolvable (broken) dependency chain
Summary: Unhelpful error message when faced with unresolvable (broken) dependency chain
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1067737 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-06 13:46 UTC by Daniel Berrangé
Modified: 2014-02-21 08:06 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-07 08:31:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Daniel Berrangé 2013-08-06 13:46:58 UTC
Description of problem:

I attempted to install virt-install with dnf and got the following bizarre/unintelligible error message

# dnf install virt-install
Setting up Install Process
Resolving Dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Error: package virt-install-0.10.0-0.5.gitde1695b2.fc19.noarch requires virt-manager-common = 0.10.0-0.5.gitde1695b2.fc19, but none of the providers can be installed


When I tried the same thing with yum, I got a much more helpful message, showing the actual problem

--> Finished Dependency Resolution
Error: Package: libvirt-python-1.0.5.4-1.fc19.x86_64 (updates)
           Requires: libvirt.so.0(LIBVIRT_PRIVATE_1.0.5.4)(64bit)
           Available: libvirt-client-1.0.5.4-1.fc19.x86_64 (updates)
               libvirt.so.0(LIBVIRT_PRIVATE_1.0.5.4)(64bit)
           Installed: libvirt-client-1.1.1-1.fc19.x86_64 (installed)
               Not found
           Available: libvirt-client-1.0.5.1-1.fc19.i686 (fedora)
               Not found
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


This showed me that I had a problem of my own making - I had installed a custom build of libvirt-client 1.1.1, which prevent dnf/yum from installing the libvirt-python in the Fedora 19 repos.


Version-Release number of selected component (if applicable):
dnf-0.3.8-2.git85524ae.fc19.noarch

How reproducible:
Not attempted, but probably always reproducable in this scenario

Steps to Reproduce:
1. Rebuild Fedora 20 libvirt RPMs, on a Fedora 19 host
2. Update the libvirt-client package to the new 1.1.1 build of libvirt
3. Ensure libvirt-python is not already installed
4. Ask dnf to install virt-install

Actual results:
Error: package virt-install-0.10.0-0.5.gitde1695b2.fc19.noarch requires virt-manager-common = 0.10.0-0.5.gitde1695b2.fc19, but none of the providers can be installed

Expected results:
Something telling me that virt-manager-common requires libvirt-python, but that the version in the repos conflicts with the libvirt-client I have installed locally.

Basically enough info that I can see what the problematic package is & resolve it.

Additional info:

Comment 1 Ales Kozumplik 2013-08-07 08:31:59 UTC
Hello Daniel,

Quite contrary I find the DNF explanation a lot more useful than what Yum outputs (which doesn't mention the conflict either). You can probably obtain the information you need by running

dnf install virt-manager-common

and see the issue in more detail.

There are inherent obstacles in generating detailed explanation why a transaction failed. For one, the solver can not know if it's a 'problem of your own making' or if there are broken packages or repositories in the way etc. E.g. maybe virt-manager-common is an unnecessary require of virt-install. Also, in this particular case, if we decide to investigate a "chain" of requires, there might be a hundred packages providing virt-manager-common, all of them uninstallable for different reasons. What chain should the analyzer follow and try to explain then? How to visualize this?

Bottom line is, the best thing to do is to report that the transaction has failed to resolve and the immediate reason why that was. Everything else is just heuristic. I wouldn't mind accepting a plugin to perform some concrete heuristic approach in the future but that is neither ongoing nor planned at the moment.

Closing as NOTABUG.

Comment 2 Ales Kozumplik 2014-02-21 08:06:23 UTC
*** Bug 1067737 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.