Description of problem: I ran a dnf update and it failed with skipping 16 packages as broken dependencies. Picking one, I tried to update kscd: [root@pmg-w541 ~]# dnf clean all 44 files removed [root@pmg-w541 ~]# dnf list updates | grep kscd Last metadata expiration check: 0:00:00 ago on Mon Jan 30 08:03:36 2017 EST. kscd.x86_64 16.12.1-1.fc26 rawhide kscd.x86_64 16.12.1-1.fc26 fedora [root@pmg-w541 ~]# rpm -q kscd kscd-16.08.2-1.fc26.x86_64 [root@pmg-w541 ~]# dnf update kscd Last metadata expiration check: 0:00:27 ago on Mon Jan 30 08:03:36 2017 EST. Dependencies resolved. Nothing to do. Complete! [root@pmg-w541 ~]# echo $? 0 [root@pmg-w541 ~]# rpm -q kscd kscd-16.08.2-1.fc26.x86_64 [root@pmg-w541 ~]# dnf should not return 0 since it didn't update kscd. dnf returns 0 for a normal update -y attempt: # dnf update -y Last metadata expiration check: 0:03:59 ago on Mon Jan 30 08:03:36 2017 EST. Dependencies resolved. ============================================================================================================================================================================================================================================= Package Arch Version Repository Size ============================================================================================================================================================================================================================================= Skipping packages with broken dependencies: PyQt4 x86_64 4.12-1.fc26 rawhide 2.9 M PyQt4-webkit x86_64 4.12-1.fc26 rawhide 125 k calibre x86_64 2.76.0-2.fc26 rawhide 29 M kscd x86_64 16.12.1-1.fc26 rawhide 169 k libgeotiff x86_64 1.4.0-8.fc26 rawhide 712 k libspatialite x86_64 4.3.0a-3.fc26 rawhide 2.5 M ogdi x86_64 3.2.0-0.27.beta2.fc26 rawhide 256 k okular x86_64 16.12.1-1.fc26 rawhide 760 k okular-libs x86_64 16.12.1-1.fc26 rawhide 305 k okular-part x86_64 16.12.1-1.fc26 rawhide 970 k proj i686 4.9.3-1.fc26 rawhide 228 k proj x86_64 4.9.3-1.fc26 rawhide 227 k python-qt5 x86_64 5.7.1-1.fc26 rawhide 3.6 M python-qt5-rpm-macros noarch 5.7.1-1.fc26 rawhide 13 k python-qt5-webkit x86_64 5.7.1-1.fc26 rawhide 120 k sip x86_64 4.19-1.fc26 rawhide 128 k Transaction Summary ============================================================================================================================================================================================================================================= Skip 16 Packages Nothing to do. Complete! # echo $? 0 Version-Release number of selected component (if applicable): dnf-2.0.0-2.fc26.noarch How reproducible: 100% Steps to Reproduce: 1. dnf update 2. have it fail for dependencies 3. # echo $? Actual results: dnf returns 0 Expected results: dnf should not exit with a 0. Additional info:
Use --best if you want to get errors.
We should provide hint after "Skipping packages with broken dependencies:" section: ~"To get the root cause why the single package was skipped, rerun "dnf --best <command> <packagename>"
(In reply to Igor Gnatenko from comment #1) > Use --best if you want to get errors. No no. I'm not talking about anything out of the ordinary. If I run dnf like normal and then check with echo $? to see if it completed successfully, that shouldn't return 0 if dnf doesn't actually fully complete the update or whatever command. Running an update and skipping those packages that have broken deps is not a successful run. That's great that dnf doesn't update packages that don't have all of the deps met, but that doesn't mean it was successfully run. Oh no! heartbleed / dirtycow / badlock ... and I need to patch! I'd better run dnf update. It said it skipped packages, but it returned 0 so that must mean I'm patched. (In reply to Honza Silhan from comment #2) > We should provide hint after "Skipping packages with broken dependencies:" > section: ~"To get the root cause why the single package was skipped, rerun > "dnf --best <command> <packagename>" That would be nice, but this bug was initially for dnf (incorrectly) returning 0 when it didn't fully run without issue.
PR: https://github.com/rpm-software-management/dnf/pull/735 (In reply to Peter Gervase from comment #3) > (In reply to Igor Gnatenko from comment #1) > > Use --best if you want to get errors. > > No no. I'm not talking about anything out of the ordinary. If I run dnf like > normal and then check with echo $? to see if it completed successfully, that > shouldn't return 0 if dnf doesn't actually fully complete the update or > whatever command. Running an update and skipping those packages that have > broken deps is not a successful run. That's great that dnf doesn't update > packages that don't have all of the deps met, but that doesn't mean it was > successfully run. > Oh no! heartbleed / dirtycow / badlock ... and I need to patch! I'd better > run dnf update. It said it skipped packages, but it returned 0 so that must > mean I'm patched. Returning non-0 code while doing partial update when user requested it is not correct. IIRC yum returns 0 when you add --skip-broken switch and because of persisting compatibility we cannot change that. > (In reply to Honza Silhan from comment #2) > > We should provide hint after "Skipping packages with broken dependencies:" > > section: ~"To get the root cause why the single package was skipped, rerun > > "dnf --best <command> <packagename>" > > That would be nice, but this bug was initially for dnf (incorrectly) > returning 0 when it didn't fully run without issue. run it with `--best` as advised above. Then it will halt and return non-0 code.