[Proposing the RFE I made in the mailing list discussion https://lists.fedoraproject.org/pipermail/devel/2015-April/209727.html] By default "dnf upgrade" (and other dnf commands) will skip over updates that cannot be installed for dependency reasons. However, it gives no indication when it does that. The user may not be aware that he's missing some updates. The dependency reasons may be more permanent than just the occasional and temporary broken dependencies in Fedora's repos. The user may have installed a 3rd party package that Requires a certain version of a Fedora package. If Fedora then releases an update of the package, the user ought to be made aware that he cannot at the same time have the system fully updated and have the 3rd party package installed. It is then up to the user to make a choice. But if "dnf upgrade" just silently skips the updates, the choice never enters the user's mind. It's been suggested that "dnf check-update" would tell the user about this fact. I conjecture that the number of users who ever use this command is orders of magnitude smaller than the number of users who just know "dnf upgrade". A couple of examples from other package managers: apt-get may say "The following packages have been kept back: ...". zypper may say "The following N package updates will NOT be installed: ...". dnf could report it like in this mockup: ... Dependencies resolved. ======================================================================== Package Arch Version Repository Size ======================================================================== Upgrading: emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M emacs-common x86_64 1:24.4-6.fc21 updates-testing 37 M emacs-filesystem noarch 1:24.4-6.fc21 updates-testing 64 k Skipping for dependency reasons: firefox x86_64 37.0.1-1.fc21 updates-testing 69 M Transaction Summary ======================================================================== Upgrade 3 Packages Skip 1 Package Total download size: ... Is this ok [y/N]:
Thank you for the report. I personally like this idea too. But if we will implement something like this, I think that scripts should benefit from this feature too and I don't think that parsing the output is very comfortable/reliable.
*** Bug 1218992 has been marked as a duplicate of this bug. ***
The biggest issue for *me* is that you can't get it to cough up the reason *why* an update doesn't happen. As I'm sitting here, I have a wireshark update pending: [~] dnf list updates | tail -4 vte291.x86_64 0.40.2-1.fc23 rawhide wireshark.x86_64 1.12.5-1.fc23 rawhide wireshark-gnome.x86_64 1.12.5-1.fc23 rawhide xulrunner.x86_64 38.0-1.fc23 rawhide [~] rpm -q wireshark wireshark-1.12.4-2.fc23.x86_64 [~] dnf update wireshark Last metadata expiration check performed 2:31:27 ago on Fri May 29 16:06:29 2015. Dependencies resolved. Nothing to do. Well, *that's* a lot of help. Fortunately, yum-deprecated is still on my laptop. [~] yum-deprecated update wireshark Yum command has been deprecated, use dnf instead. See 'man dnf' and 'man yum2dnf' for more information. Loaded plugins: auto-update-debuginfo, changelog, dellsysid, keys, refresh-updatesd Resolving Dependencies --> Running transaction check ---> Package wireshark.x86_64 0:1.12.4-2.fc23 will be updated --> Processing Dependency: wireshark = 1.12.4-2.fc23 for package: wireshark-gnome-1.12.4-2.fc23.x86_64 ---> Package wireshark.x86_64 0:1.12.5-1.fc23 will be an update --> Processing Dependency: libgnutls.so.30(GNUTLS_3_4)(64bit) for package: wireshark-1.12.5-1.fc23.x86_64 --> Processing Dependency: libgnutls.so.30()(64bit) for package: wireshark-1.12.5-1.fc23.x86_64 --> Running transaction check ---> Package gnutls.x86_64 0:3.3.14-1.fc23 will be updated --> Processing Dependency: gnutls(x86-64) = 3.3.14-1.fc23 for package: gnutls-dane-3.3.14-1.fc23.x86_64 (... skipping...) ---> Package gnutls.x86_64 0:3.4.1-1.fc23 will be an update --> Processing Dependency: libnettle.so.6(NETTLE_6)(64bit) for package: gnutls-3.4.1-1.fc23.x86_64 (... skipping some more ...) --> Finished Dependency Resolution Error: Package: gstreamer1-plugins-bad-freeworld-1.4.5-2.fc22.x86_64 (installed) Requires: libnettle.so.4()(64bit) Removing: nettle-2.7.1-6.fc23.x86_64 (@rawhide) libnettle.so.4()(64bit) Updated By: nettle-3.1.1-1.fc23.x86_64 (rawhide) ~libnettle.so.6()(64bit) Aha. That's linked against an older release of libnettle, so wireshark won't update until either that RPM gets rebuilt, or I remove it, or something. Now as it turns out, that RPM is only on my system for the benefit of 1 rarely used program - so now knowing where the *real* problem is, I can decide whether to remove the program and the plugins RPM, or rebuild them from source against newer libraries, or just wait for somebody else to refresh it, or just live with the fact that wireshark won't be updated for a bit. But you can't make that decision without information. And although in this case it's an rpmfusion issue, this same thing happens *ALL THE TIME* in rawhide - libfoo updates and libfoo.so.2 is now libfoo.so.3, and then LibreOffice won't update because they jumped right on it and rebuilt against .so.3 - but now you're stuck for possibly days until wombat-0.13 gets rebuilt against the new libs. This is particularly annoying when you're chasing a bug against a Rawhide RPM, the developer patches it, you snarf it off koji - and you can't easily install it to test and provide feedback.... And although yum would *tell* you which RPM actually had the dependency issue, there's no way I can see to get dnf to cough up the name of the actual offender. Yes, in a perfect world, every single package that depended on a library would get rebuilt that same night and pushed out, on every repo ever. This is, however, not how the real world works.
FYI, I had success with using dnf install NVR or dnf update --best. It doesn't give you information as detailed as yum did but it gives you at least something.
For error description improvement we have tracked other report. Lets have this for listing skipped packages in the "Skipped" column only. We need to figure out if we can get the information from dependency solver or run it internally twice with `--best` set or not.
*** Bug 1225227 has been marked as a duplicate of this bug. ***
PR: https://github.com/rpm-software-management/dnf/pull/304
*** Bug 1244998 has been marked as a duplicate of this bug. ***
dnf-1.0.2-2.fc22,hawkey-0.5.9-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-1.0.2-2.fc22,hawkey-0.5.9-2.fc22
Sorry, this doesn't work, or it does not work in all cases, I don't know. For example, this package is broken, since it is actually Rawhide build: # dnf update --assumeno https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-22-x86_64/doublecmd-gtk-0.7.0-0.svn6102.fc24/doublecmd-gtk-0.7.0-0.svn6102.fc24.x86_64.rpm Last metadata expiration check performed 0:03:50 ago on Wed Jul 22 12:41:58 2015. The downloaded packages were saved in cache till the next successful transaction. You can remove cached packages by executing 'dnf clean packages' Error: nothing provides libdbus-1.so.3(LIBDBUS_1_3)(64bit) needed by doublecmd-gtk-0.7.0-0.svn6102.fc24.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages) It is listed by check-update: # dnf check-update | grep doublecmd doublecmd-gtk.x86_64 0.7.0-0.svn6102.fc24 vondruch-doublecmd But it is not mentioned by check-update: # dnf update --assumeno |& grep doublecmd
Forgot to mention: $ rpm -q dnf dnf-1.0.2-2.fc22.noarch
Maybe you can share a reproducer and/or follow these instructions: https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#dependency-resolution-problem?
On F22: 1) Install older version of Double Commander: # dnf install https://copr-be.cloud.fedoraproject.org/results/vondruch/doublecmd/fedora-rawhide-x86_64/doublecmd-gtk-0.7.0-0.svn5869.fc23/doublecmd-gtk-0.7.0-0.svn5869.fc23.x86_64.rpm 2) Get this Rawhide repo, where is available updated, non-installable Double Commander version: https://copr.fedoraproject.org/coprs/vondruch/doublecmd/repo/fedora-rawhide/vondruch-doublecmd-fedora-rawhide.repo 3) Try "dnf check-update" and "dnf update"
Thanks. I already did that but on Rawhide where the upgrade succeeds.
Right, Jan, the problem is that neither "dnf --best --allowerasing update doublecmd-gtk" can solve this: Last metadata expiration check performed 0:18:48 ago on Wed Jul 22 15:14:50 2015. Error: nothing provides libdbus-1.so.3(LIBDBUS_1_3)(64bit) needed by doublecmd-gtk-0.7.0-0.svn6102.fc24.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages)
It was fixed for packages which had conflicts and could be resolved by `--best --allowerasing`. Right, the packages with unsatisfiable dependencies are not shown. We will fix this. They will be shown in a separate row.
*** Bug 1226930 has been marked as a duplicate of this bug. ***
*** Bug 1231333 has been marked as a duplicate of this bug. ***
PR fixing the bug from comment 13: https://github.com/rpm-software-management/dnf/pull/322
I think this will solve puzzles like 'dnf install shogun' returns clean but useless info on rawhide.
*** Bug 1243007 has been marked as a duplicate of this bug. ***
Package dnf-1.0.2-3.fc22, hawkey-0.5.9-3.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-1.0.2-3.fc22 hawkey-0.5.9-3.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-12577/dnf-1.0.2-3.fc22,hawkey-0.5.9-3.fc22 then log in and leave karma (feedback).
dnf-plugins-core-0.1.10-1.fc23,dnf-1.1.0-1.fc23,hawkey-0.6.0-1.fc23 has been submitted as an update for Fedora 23. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.10-1.fc23,dnf-1.1.0-1.fc23,hawkey-0.6.0-1.fc23
dnf-plugins-core-0.1.10-1.fc22,dnf-1.1.0-1.fc22,hawkey-0.6.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.10-1.fc22,dnf-1.1.0-1.fc22,hawkey-0.6.0-1.fc22
dnf-1.0.2-3.fc22, hawkey-0.5.9-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
dnf-plugins-core-0.1.10-1.fc22, hawkey-0.6.0-1.fc22, dnf-1.1.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
dnf-plugins-core-0.1.10-1.fc23, hawkey-0.6.0-1.fc23, dnf-1.1.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.