Hello, thank you for the report. The issue has been already reported and resolved, please see bug 988778.

*** This bug has been marked as a duplicate of bug 988778 ***

(In reply to Ales Kozumplik from comment #1)
> Hello, thank you for the report. The issue has been already reported and
> resolved, please see bug 988778.

You cannot be really serious, are you?  A quick experiment with a package Macaulay2, which has broken dependencies in the current rawhide, reveals that
'yum install --skip-broken Macaulay2' results in:

Packages skipped because of dependency problems:
    4ti2-1.6.2-3.fc21.x86_64 from rawhide
    4ti2-libs-1.6.2-3.fc21.x86_64 from rawhide
    Macaulay2-1.5-5.fc21.x86_64 from rawhide
    cddlib-094g-9.fc20.x86_64 from rawhide
    factory-gftables-3.1.5-13.fc21.noarch from rawhide
    flint-2.4.2-2.fc21.x86_64 from rawhide
    gf2x-1.1-3.fc20.x86_64 from rawhide
    gfan-0.5-8.fc21.x86_64 from rawhide
    glpk-4.53-1.fc21.x86_64 from rawhide
    libnormaliz-2.10.1-2.fc21.x86_64 from rawhide
    normaliz-2.10.1-2.fc21.x86_64 from rawhide
    ntl-6.1.0-1.fc21.x86_64 from rawhide
    pari-2.5.5-1.fc21.x86_64 from rawhide

plus a detailed chain of dependencies showing what is happening here and why the failure. This chain happens here to be quite long so try it yourself.

With 'dnf install --best Macaulay2' the whole output looks like this:

Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Error: nothing provides libntl.so.2()(64bit) needed by Macaulay2-1.5-5.fc21.x86_64

leaving me scratching my head.  Even if on occasion that may be enough to start guessing in many cases this is grossly inadequate.

Besides see also bug 1084553.

Michael, please stop interfering with our triaging process. This has been internally discussed and settled many times before. DNF is aimed at regular users, who do not and should not know even what dependencies are.

Closing again per comment 1.

*** This bug has been marked as a duplicate of bug 988778 ***

Ales, I tend to agree with Michal.

I tried it (although Macaulay2 seems to be fixed now) and in my case yum say:

yum install --releasever=rawhide python3-libs
...
Error: Package: libpeas-1.10.0-1.fc21.x86_64 (fedora)
           Requires: libpython3.3m.so.1.0()(64bit)
           Removing: python3-libs-3.3.2-11.fc20.x86_64 (installed)
               libpython3.3m.so.1.0()(64bit)
           Updated By: python3-libs-3.4.0-6.fc21.x86_64 (bkabrda-python-3.4)

While dnf say:
dnf upgrade --best --releasever=rawhide python3-libs
Error: package python3-hawkey-0.4.12-1.fc20.x86_64 requires libpython3.3m.so.1.0()(64bit), but none of the providers can be installed

I agree that for most users is current DNF output sufficient. But it does not help with reporting errors.
Because DNF say what happened and even why, but does not reveal root of the cause, which is buried in transitive dependencies.
Therefore if I want to report broken deps (which I do pretty often before GA). I would have to manually search why (in my case) python3-hawkey require libpython3.3m.so.1.0. And find that some of its deps require it and would have to go one package by one package and manually find it.

If you can introduce --reveal-real-cause-of-broken-deps or even another tool or simple HOWTO,  then it would really help people doing QA of Fedora.

I do see your and Michal's point of view. The thing is that DNF is not a QA tool, neither a rel-eng tool. People who take on such tasks should use their own tools, perhaps in the form of plugins to DNF. For the time being there is no intention and no plan from our team to work on an extension like that, thus no open bugzilla. If you can supply the patch, that would be fine. Otherwise the only thing the community users can do to change our mind would be if enough (20 or so) of them is CCed on the original bug.

Another thing I'd like to mention (again): if there's a chain of dependencies that end up unresolvable, an automatic tool can not in many (most?) cases point out which exact piece of the chain is broken. Such tool has to take the right, heuristic steps not to spew hundreds of lines of undecipherable dependency information as Yum sometimes does.

At one end there are the end users who might not know what a package is, but at the other end there are people like packagers who need to be able to figure out why something is not working. I can understand not wanting to spit out mile-long dependency debug dumps by default, but there should be a way to get that information in a form that can be deciphered by packagers, rel-eng, QA, or simply just experienced users who might be helping an end-user sort out a problem on a mailing list. You certainly dont want everybody with a depsolving problem to file a bug :)

To follow up #5 and to be precise. The original (aka voting BZ is bug 988778)

I think the ideal approach here would be:

1. If user asks for something to be installed and we can't install it, inform him in a simple way. I think this is great:

> Error: nothing provides libntl.so.2()(64bit) needed by Macaulay2-1.5-5.fc21.x86_64

2. If the user runs dnf with --debuglevel 10 (or similar), show more detailed information helpful for more experienced users. Fedora has chosen not to target the general audience (like Ubuntu), but a bit more experienced users or users likely to contribute (e.g. in a form of bug reports), so it would be appropriate to have an easy way of getting a bit more advanced functionality from our tools. It doesn't have to be the default behavior (the yum output is often too technical), but it would be nice to have it simply available, at least from my QA point of view. If I need to install additional diagnostics software to every VM or everytime I boot a Live image just to see proper broken dep info, I won't be very happy.

Of course, it would be sufficient to print those extra information to dnf.log and not on the screen. It's not important whether people need to use --debug or inspect a log file, as long as it is available somewhere.

not a dup of that other bug, hard to believe there's none other like this I can find. Let's keep the discussion running here.

Regarding comment #4:
Unfortunately there's no "root cause", a problem always consists of a number of dependencies and jobs that keep a package from being used.

libsolv uses some heuristic to select one of the deps to present it as "cause" to the user, there's also the possibility to display all of the involved deps. But while this is really useful to find out what's going on it will confuse every "normal" user, so I do not suggest to make this the default. But maybe you might add an option to select this?

I can also tweak the heuristic to prefer "no provider of a dep" errors, if this is what happens in Rawhide all the time. Dunno if that would help you.

I can also add a function that returns where the "best" package could not be installed, if you want something like yum's "skipped because of dependency problems".

We sort of discussed the same thing here Ales: https://bugzilla.redhat.com/show_bug.cgi?id=1060522

When I have package dependency problems in Fedora, most commonly I remove the packages that are blocking updates. (Though sometimes I can't do that and still have something I need.) The way that normally works is to use "yum update -y -v | grep -i fail". However sometimes you don't really need to remove all of the listed packages to be able to update everything. Also occasionally something is blocking updates and doesn't show up will a failed update. This list can be significantly shorter than the full list of packages with updates that can't currently be done with the currently installed packages.

(In reply to Michael Schröder from comment #10)
> Regarding comment #4:
> Unfortunately there's no "root cause", a problem always consists of a number
> of dependencies and jobs that keep a package from being used.
> 
> libsolv uses some heuristic to select one of the deps to present it as
> "cause" to the user, there's also the possibility to display all of the
> involved deps. But while this is really useful to find out what's going on
> it will confuse every "normal" user, so I do not suggest to make this the
> default. But maybe you might add an option to select this?

I think we talked about this before---can you please remind me how to trigger it in libsolv?

> 
> I can also tweak the heuristic to prefer "no provider of a dep" errors, if
> this is what happens in Rawhide all the time. Dunno if that would help you.

I doubt this is what will stop complementary group of users to open an analogical bug.
 
> I can also add a function that returns where the "best" package could not be
> installed, if you want something like yum's "skipped because of dependency
> problems".

While it would be nice I am not sure we'd want to use it in DNF by default: having things silent doesn't prevent the QA from finding out dependency bugs and OTOH prevents avalanche of dupes from avid users.

If you want all deps listed you need to use solver_findallproblemrules() instead of solver_findproblemrule() in hawkey's hy_goal_describe_problem() function.