Bug 1210445 - [rfe] report when skipping available updates due to dependency reasons
[rfe] report when skipping available updates due to dependency reasons
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: Honza Silhan
Fedora Extras Quality Assurance
: FutureFeature
: 1218992 1225227 1226930 1231333 1243007 1244998 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-09 14:25 EDT by Michal Schmidt
Modified: 2015-08-19 03:50 EDT (History)
18 users (show)

See Also:
Fixed In Version: dnf-plugins-core-0.1.10-1.fc23
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-10 22:08:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2015-04-09 14:25:42 EDT
[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]:
Comment 1 Radek Holy 2015-04-10 07:21:56 EDT
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.
Comment 2 Radek Holy 2015-05-25 05:11:22 EDT
*** Bug 1218992 has been marked as a duplicate of this bug. ***
Comment 3 Valdis Kletnieks 2015-05-29 19:03:28 EDT
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.
Comment 4 Jan Zeleny 2015-06-01 02:30:47 EDT
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.
Comment 5 Honza Silhan 2015-06-01 06:27:18 EDT
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.
Comment 6 Bruno Wolff III 2015-06-01 15:50:50 EDT
*** Bug 1225227 has been marked as a duplicate of this bug. ***
Comment 7 Honza Silhan 2015-07-04 17:25:03 EDT
PR: https://github.com/rpm-software-management/dnf/pull/304
Comment 8 Radek Holy 2015-07-21 07:19:40 EDT
*** Bug 1244998 has been marked as a duplicate of this bug. ***
Comment 9 Fedora Update System 2015-07-22 04:25:12 EDT
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
Comment 10 Vít Ondruch 2015-07-22 06:48:12 EDT
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
Comment 11 Vít Ondruch 2015-07-22 06:48:30 EDT
Forgot to mention:

$ rpm -q dnf
dnf-1.0.2-2.fc22.noarch
Comment 12 Radek Holy 2015-07-22 08:41:30 EDT
Maybe you can share a reproducer and/or follow these instructions: https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#dependency-resolution-problem?
Comment 13 Vít Ondruch 2015-07-22 08:51:32 EDT
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"
Comment 14 Radek Holy 2015-07-22 09:19:59 EDT
Thanks. I already did that but on Rawhide where the upgrade succeeds.
Comment 15 Radek Holy 2015-07-22 09:37:24 EDT
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)
Comment 16 Honza Silhan 2015-07-22 12:47:56 EDT
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.
Comment 17 Honza Silhan 2015-07-24 05:35:57 EDT
*** Bug 1226930 has been marked as a duplicate of this bug. ***
Comment 18 Honza Silhan 2015-07-24 09:00:17 EDT
*** Bug 1231333 has been marked as a duplicate of this bug. ***
Comment 19 Honza Silhan 2015-07-27 11:52:16 EDT
PR fixing the bug from comment 13: https://github.com/rpm-software-management/dnf/pull/322
Comment 20 Christopher Meng 2015-07-28 03:16:27 EDT
I think this will solve puzzles like 'dnf install shogun' returns clean but useless info on rawhide.
Comment 21 Honza Silhan 2015-07-29 10:33:22 EDT
*** Bug 1243007 has been marked as a duplicate of this bug. ***
Comment 22 Fedora Update System 2015-07-31 22:28:23 EDT
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).
Comment 23 Fedora Update System 2015-08-10 06:05:08 EDT
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
Comment 24 Fedora Update System 2015-08-10 06:49:41 EDT
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
Comment 25 Fedora Update System 2015-08-10 22:08:20 EDT
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.
Comment 26 Fedora Update System 2015-08-14 22:13:48 EDT
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.
Comment 27 Fedora Update System 2015-08-19 03:50:58 EDT
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.

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