Description of problem: I wanted to update my system and some new packages are marked to be installed. But I don't see any reason why. Is it a new dependency of some existing package? Is it a new required package in some existing package group? Please make the output indicate that somehow. See protobuf-c in: http://paste.fedoraproject.org/63189/raw/ Version-Release number of selected component (if applicable): dnf-0.4.9-1.fc20.noarch
Hi Kamil, DNF does not yet support groups as objects so it does not check whether the comps have changed and new packages will be installed. When we decide to support it we can add this output. As for changed dependencies of an existing package: we don't know concrete reasons why a resolving ended with particular results and that's a good thing. We only guarantee the user that the result is optimal (from libsolv's point of view) and that we don't introduce any inconsistencies into the RPMDB. There's nothing we are going to do more in this area. Not sure what to do with the bug now: it asks for a feature of something that does not exist. Do you want to open a bug for groups as objects or can I close this?
---> Package protobuf-c.x86_64 0.15-8.fc20 will be installed ---> Package protobuf-compiler.x86_64 2.5.0-5.fc20 will be installed All the others are just updates. It's probably just a dependency of some updated package. run: "rpm -q --whatrequires protobuf-c" to find what pulled this in.
> we don't know concrete reasons why a resolving ended with particular results Oh, interesting. But a bit unfortunate, from user POV. Yum tells me something like this: ---> Package libgadu.x86_64 0:1.12.0-0.2.rc1.fc20 will be an update --> Processing Dependency: libprotobuf-c.so.0()(64bit) for package: libgadu-1.12.0-0.2.rc1.fc20.x86_64 In this example, it's very simple. But sometimes I see a large number of dependencies added and an output like the above really helps. Sometimes I discover that a completely useless package caused it and I rather remove it (prior to upgrade) than to download and install lots of its dependencies. Hm, hm, would it be possible to do something like this? If there are new packages installed during upgrade, compare their requirements with provisions of the to-be-upgraded set of packages and print a similar output: ---> Package protobuf-c.x86_64 0.15-8.fc20 will be installed -----> A dependency of: libgadu-1.12.0-0.2.rc1.fc20 But hey, maybe I don't need this, maybe I'll get used to the missing information. I was simply used to see it with yum. I reported this bug because I believed it was simply an omission inside dnf. If you decide not to implement this, just close this (and keep in mind this could be useful for package group updates).
Yum shows these 'Processing Dependency' lines but they do more confusion than good. I'll document this properly so people know we don't do it on purpose.
Documented in cc438a3, will be included in dnf-0.4.10.
dnf-0.4.10-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.4.10-1.fc20
Package dnf-0.4.10-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-0.4.10-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0089/dnf-0.4.10-1.fc20 then log in and leave karma (feedback).
dnf-0.4.10-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Would it be possible to get verbose output to see these? My use case: installing a bunch of -devel packages for some project and trimming out those which are dragging in too much (maybe it chains off into KDE-land, Java-land or something). Without the output, tracking down the cause of some huge dependency chain would get much harder. I also file bugs about over-broad Requires which this helps with. Hmm...<musing ignorability="high">Maybe dumping out DOT files for a transaction would be useful (edge colors being the action/reasoning).</musing>
(In reply to Ales Kozumplik from comment #4) Says who? What if I want to parse DNF output? What if I want to understand what additional dependencies a certain updated package brings? Please, show this information or at least give an option to show it.
I request this bug to be reopened. Dumbing down every app just because you get confused by several additional lines of output is not an excuse for removing crucial information.
(In reply to Artem S. Tashkinov from comment #11) > I request this bug to be reopened. > > Dumbing down every app just because you get confused by several additional > lines of output is not an excuse for removing crucial information. Seconding this. I'm currently sitting here on Fedora Rawhide, and 'dnf list updates' shows 'wireshark'. Saying 'dnf update wireshark' says "nothing to do". At leas if you did 'yum update wireshark', it would go down the list of updates, pre-req updates, and finally blow up and say (verbosely) "sorry, no can do, because wireshark wants libfoo-0.17, but moby-wooble still needs libfoo-0.16". I can find no way to get the equivalent reason of *why* the dnf update solver thinks there's nothing to do for 'update wireshark'. As several others have pointed out, often the problem is some obscure 3rd party RPM linked against an older library, and removing the un-needed RPM allows the update to complete (I'm looking at *you*, rpmfusion :)
Do check this http://dnf.readthedocs.org/en/latest/user_faq.html#why-are-dnf-check-update-packages-not-marked-for-upgrade-in-the-following-dnf-upgrade Try "dnf update wireshark --best"
Also note that there is this RFE: bug 1210445. It will at least print the "wireshark" part. The "libfoo" part is another story.
I know this is old and closed, but I found it while searching for a solution to the problem it addresses. I agree with comment 12. I'm sitting here in rawhide for F25, and when I do a dnf upgrade, 366 packages are skipped. But I have no way of knowing *why* they were skipped. If I want to open a ticket to get an update to a dependent package, I have no idea which package I should open it against. I try dnf update --best, and get a list of 30 dependencies that are not met, so still haven't a concrete idea of which package needs to be updated to satisfy dependencies. It's like a logjam, and I want to know the one log that is holding back the whole jam. Maybe there should be a new program, say 'why-dnf-dependencies-fail-for' that can be run on a package, and spit out the package that is causing the dependency failure. Or maybe it already exists under another name. There, I feel better after my rant. :-)