Description of problem: I did a dnf clean all; dnf check-update and it showed a bunch of package updates available. However, when I ran dnf update, it said nothing to do. Not sure what's happening here. Version-Release number of selected component (if applicable): [asinha@ankur-laptop ~]$ rpm -q dnf librepo hawkey dnf-0.4.12-1.git3584018.fc20.noarch librepo-1.5.2-2.gitb9bafb7.fc20.x86_64 hawkey-0.4.9-1.git1d1a1e4.fc20.x86_64 How reproducible: Once till now Steps to Reproduce: 1.run dnf check-update and note available updates 2.run dnf update to update the system 3. Actual results: Shows available updates but update says nothing to do Expected results: Should update, shouldn't it? Additional info: All commands were run as sudo of course, [asinha@ankur-laptop Downloads]$ sudo dnf check-update Config time: 0.007 cachedir: /var/cache/dnf/x86_64/20 Loaded plugins: generate_completion_cache, kickstart, noroot initialized Noroot plugin dnf version: 0.4.12 Command: dnf check-update Installroot: / Base command: check-update Extra commands: [] repo: using cache for: updates-testing repo: using cache for: fedora not found deltainfo for: Fedora 20 - x86_64 repo: using cache for: rpmfusion-free-updates not found deltainfo for: RPM Fusion for Fedora 20 - Free - Updates repo: using cache for: adobe-linux-x86_64 not found deltainfo for: Adobe Systems Incorporated repo: using cache for: Dropbox not found deltainfo for: Dropbox Repository repo: using cache for: rpmfusion-nonfree-updates not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree - Updates repo: using cache for: rpmfusion-free not found deltainfo for: RPM Fusion for Fedora 20 - Free repo: using cache for: dnf-nightlies not found deltainfo for: DNF nightlies for Fedora 20 - x86_64 repo: using cache for: fedora-rawhide-kernel-nodebug not found deltainfo for: Rawhide kernels built without debugging turned on repo: using cache for: updates repo: using cache for: rpmfusion-nonfree not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree repo: using cache for: ryanlerch-corebird-unstable not found deltainfo for: Copr repo for corebird-unstable owned by ryanlerch hawkey sack setup time: 0.317 libvirt-client.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-interface.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-network.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nodedev.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nwfilter.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-qemu.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-secret.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-storage.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-kvm.x86_64 1.1.3.3-4.fc20 updates-testing [asinha@ankur-laptop Downloads]$ sudo dnf update Config time: 0.008 cachedir: /var/cache/dnf/x86_64/20 Loaded plugins: generate_completion_cache, kickstart, noroot initialized Noroot plugin dnf version: 0.4.12 Command: dnf update Installroot: / Base command: upgrade Extra commands: [] repo: using cache for: updates-testing repo: using cache for: fedora not found deltainfo for: Fedora 20 - x86_64 repo: using cache for: rpmfusion-free-updates not found deltainfo for: RPM Fusion for Fedora 20 - Free - Updates repo: using cache for: adobe-linux-x86_64 not found deltainfo for: Adobe Systems Incorporated repo: using cache for: Dropbox not found deltainfo for: Dropbox Repository repo: using cache for: rpmfusion-nonfree-updates not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree - Updates repo: using cache for: rpmfusion-free not found deltainfo for: RPM Fusion for Fedora 20 - Free repo: using cache for: dnf-nightlies not found deltainfo for: DNF nightlies for Fedora 20 - x86_64 repo: using cache for: fedora-rawhide-kernel-nodebug not found deltainfo for: Rawhide kernels built without debugging turned on repo: using cache for: updates repo: using cache for: rpmfusion-nonfree not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree repo: using cache for: ryanlerch-corebird-unstable not found deltainfo for: Copr repo for corebird-unstable owned by ryanlerch hawkey sack setup time: 0.322 Resolving dependencies --> Starting dependency resolution --> Finished dependency resolution Depsolve time: 0.811 Dependencies resolved. Nothing to do. [asinha@ankur-laptop Downloads]$
Cleaned metadata again and got same result: [asinha@ankur-laptop Downloads]$ sudo clean all [asinha@ankur-laptop Downloads]$ sudo dnf update Config time: 0.008 cachedir: /var/cache/dnf/x86_64/20 Loaded plugins: generate_completion_cache, kickstart, noroot initialized Noroot plugin dnf version: 0.4.12 Command: dnf update Installroot: / Base command: upgrade Extra commands: [] repo: downloading from remote: updates-testing Fedora 20 - x86_64 - Test Updates 613 kB/s | 5.9 MB 00:09 repo: downloading from remote: fedora Fedora 20 - x86_64 616 kB/s | 36 MB 00:59 not found deltainfo for: Fedora 20 - x86_64 repo: downloading from remote: rpmfusion-free-updates RPM Fusion for Fedora 20 - Free - Updates 228 kB/s | 143 kB 00:00 not found deltainfo for: RPM Fusion for Fedora 20 - Free - Updates repo: downloading from remote: adobe-linux-x86_64 Adobe Systems Incorporated 2.0 kB/s | 1.8 kB 00:00 not found deltainfo for: Adobe Systems Incorporated repo: downloading from remote: Dropbox Dropbox Repository 4.7 kB/s | 2.4 kB 00:00 not found deltainfo for: Dropbox Repository repo: downloading from remote: rpmfusion-nonfree-updates RPM Fusion for Fedora 20 - Nonfree - Updates 247 kB/s | 37 kB 00:00 not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree - Updates repo: downloading from remote: rpmfusion-free RPM Fusion for Fedora 20 - Free 559 kB/s | 487 kB 00:00 not found deltainfo for: RPM Fusion for Fedora 20 - Free repo: downloading from remote: dnf-nightlies DNF nightlies for Fedora 20 - x86_64 22 kB/s | 13 kB 00:00 not found deltainfo for: DNF nightlies for Fedora 20 - x86_64 repo: downloading from remote: fedora-rawhide-kernel-nodebug Rawhide kernels built without debugging turned on 111 kB/s | 211 kB 00:01 not found deltainfo for: Rawhide kernels built without debugging turned on repo: downloading from remote: updates Fedora 20 - x86_64 - Updates 613 kB/s | 15 MB 00:24 repo: downloading from remote: rpmfusion-nonfree RPM Fusion for Fedora 20 - Nonfree 347 kB/s | 289 kB 00:00 not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree repo: downloading from remote: ryanlerch-corebird-unstable Copr repo for corebird-unstable owned by ryanlerch 5.2 kB/s | 2.9 kB 00:00 not found deltainfo for: Copr repo for corebird-unstable owned by ryanlerch hawkey sack setup time: 139.380 Completion plugin: Generating completion cache... Resolving dependencies --> Starting dependency resolution --> Finished dependency resolution Depsolve time: 0.485 Dependencies resolved. Nothing to do. [asinha@ankur-laptop Downloads]$ sudo dnf check-update Config time: 0.011 cachedir: /var/cache/dnf/x86_64/20 Loaded plugins: generate_completion_cache, kickstart, noroot initialized Noroot plugin dnf version: 0.4.12 Command: dnf check-update Installroot: / Base command: check-update Extra commands: [] repo: using cache for: updates-testing repo: using cache for: fedora not found deltainfo for: Fedora 20 - x86_64 repo: using cache for: rpmfusion-free-updates not found deltainfo for: RPM Fusion for Fedora 20 - Free - Updates repo: using cache for: adobe-linux-x86_64 not found deltainfo for: Adobe Systems Incorporated repo: using cache for: Dropbox not found deltainfo for: Dropbox Repository repo: using cache for: rpmfusion-nonfree-updates not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree - Updates repo: using cache for: rpmfusion-free not found deltainfo for: RPM Fusion for Fedora 20 - Free repo: using cache for: dnf-nightlies not found deltainfo for: DNF nightlies for Fedora 20 - x86_64 repo: using cache for: fedora-rawhide-kernel-nodebug not found deltainfo for: Rawhide kernels built without debugging turned on repo: using cache for: updates repo: using cache for: rpmfusion-nonfree not found deltainfo for: RPM Fusion for Fedora 20 - Nonfree repo: using cache for: ryanlerch-corebird-unstable not found deltainfo for: Copr repo for corebird-unstable owned by ryanlerch hawkey sack setup time: 0.312 libvirt-client.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-interface.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-network.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nodedev.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nwfilter.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-qemu.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-secret.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-storage.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-kvm.x86_64 1.1.3.3-4.fc20 updates-testing [asinha@ankur-laptop Downloads]$
I seem to have narrowed it down. These are the packages that check-updates says are available: libvirt-client.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-interface.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-network.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nodedev.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nwfilter.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-qemu.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-secret.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-storage.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-kvm.x86_64 1.1.3.3-4.fc20 updates-testing This is what I have installed: [asinha@ankur-laptop Downloads]$ rpm -qa \*libvirt\* libvirt-daemon-driver-nodedev-1.1.3.3-3.fc20.x86_64 libvirt-daemon-driver-storage-1.1.3.3-3.fc20.x86_64 libvirt-daemon-1.1.3.3-3.fc20.x86_64 libvirt-daemon-driver-qemu-1.1.3.3-3.fc20.x86_64 libvirt-client-1.1.3.3-3.fc20.x86_64 libvirt-daemon-driver-interface-1.1.3.3-3.fc20.x86_64 libvirt-daemon-driver-secret-1.1.3.3-3.fc20.x86_64 libvirt-daemon-kvm-1.1.3.3-3.fc20.x86_64 libvirt-gobject-0.1.7-2.fc20.x86_64 libvirt-daemon-driver-network-1.1.3.3-3.fc20.x86_64 libvirt-daemon-driver-nwfilter-1.1.3.3-3.fc20.x86_64 libvirt-gconfig-0.1.7-2.fc20.x86_64 libvirt-glib-0.1.7-2.fc20.x86_64 This is what bodhi says is available for updates: [asinha@ankur-laptop Downloads]$ bodhi -L libvirt f19-updates-testing libvirt-1.0.5.9-1.fc19 f19-updates-candidate libvirt-1.0.5.9-1.fc19 f19-updates libvirt-1.0.5.9-1.fc19 f20-updates-candidate libvirt-1.1.3.3-5.fc20 f20-updates libvirt-1.1.3.3-2.fc20 f20-updates-testing libvirt-1.1.3.1-2.fc20 [asinha@ankur-laptop Downloads]$ It looks like the 1.1.3.3-4 version was unpushed, and a 1.1.3.3-5 pushed instead. So, the metadata at the mirror could be outdated. The mirror it tries to download from (not sure if this should be the same mirror it got metadata from) may not have the packages any more? It should say something like "Cannot download package" or something, though? https://admin.fedoraproject.org/updates/libvirt
Yum output ;) [asinha@ankur-laptop Downloads]$ sudo yum clean all; sudo yum check-update [sudo] password for asinha: Loaded plugins: langpacks, refresh-packagekit Cleaning repos: Dropbox adobe-linux-x86_64 fedora fedora-rawhide-kernel-nodebug rpmfusion-free rpmfusion-free-updates rpmfusion-nonfree rpmfusion-nonfree-updates : ryanlerch-corebird-unstable updates updates-testing dnf-nightlies Cleaning up everything Loaded plugins: langpacks, refresh-packagekit Dropbox | 951 B 00:00:00 adobe-linux-x86_64 | 951 B 00:00:00 fedora/20/x86_64/metalink | 3.7 kB 00:00:00 fedora | 3.8 kB 00:00:00 fedora-rawhide-kernel-nodebug | 2.9 kB 00:00:00 rpmfusion-free | 3.3 kB 00:00:00 rpmfusion-free-updates | 3.3 kB 00:00:00 rpmfusion-nonfree | 3.3 kB 00:00:00 rpmfusion-nonfree-updates | 3.3 kB 00:00:00 ryanlerch-corebird-unstable | 3.0 kB 00:00:00 updates/20/x86_64/metalink | 3.6 kB 00:00:00 updates | 4.6 kB 00:00:00 updates-testing/20/x86_64/metalink | 2.8 kB 00:00:00 updates-testing | 4.6 kB 00:00:00 dnf-nightlies | 2.9 kB 00:00:00 (1/9): fedora-rawhide-kernel-nodebug/x86_64/primary_db | 9.4 kB 00:00:00 (2/9): ryanlerch-corebird-unstable/20/x86_64/primary_db | 3.2 kB 00:00:00 (3/9): fedora/20/x86_64/group_gz | 394 kB 00:00:03 (4/9): updates-testing/20/x86_64/group_gz | 394 kB 00:00:04 (5/9): updates/20/x86_64/group_gz | 394 kB 00:00:05 (6/9): dnf-nightlies/20/x86_64/primary_db | 11 kB 00:00:00 (7/9): updates-testing/20/x86_64/primary_db | 2.1 MB 00:00:09 (8/9): updates/20/x86_64/primary_db | 7.2 MB 00:00:31 (9/9): fedora/20/x86_64/primary_db | 18 MB 00:00:49 (1/14): rpmfusion-free/20/x86_64/group_gz | 1.6 kB 00:00:00 (2/14): rpmfusion-free-updates/20/x86_64/group_gz | 1.6 kB 00:00:00 (3/14): rpmfusion-nonfree/20/x86_64/group_gz | 1.0 kB 00:00:00 (4/14): Dropbox/20/primary | 1.5 kB 00:00:00 (5/14): rpmfusion-nonfree-updates/20/x86_64/group_gz | 1.0 kB 00:00:00 (6/14): rpmfusion-free/20/x86_64/primary_db | 445 kB 00:00:01 (7/14): rpmfusion-free-updates/20/x86_64/primary_db | 108 kB 00:00:00 (8/14): rpmfusion-nonfree-updates/20/x86_64/primary_db | 35 kB 00:00:00 (9/14): adobe-linux-x86_64/primary | 1.2 kB 00:00:01 (10/14): rpmfusion-nonfree/20/x86_64/primary_db | 137 kB 00:00:01 (11/14): updates-testing/20/x86_64/updateinfo | 217 kB 00:00:01 (12/14): updates/20/x86_64/updateinfo | 650 kB 00:00:02 (13/14): updates/20/x86_64/pkgtags | 856 kB 00:00:04 (14/14): updates-testing/20/x86_64/pkgtags | 856 kB 00:00:04 Dropbox 4/4 adobe-linux-x86_64 2/2 libvirt-client.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-interface.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-network.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nodedev.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-nwfilter.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-qemu.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-secret.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-driver-storage.x86_64 1.1.3.3-4.fc20 updates-testing libvirt-daemon-kvm.x86_64 1.1.3.3-4.fc20 updates-testing [asinha@ankur-laptop Downloads]$ sudo yum update Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package libvirt-client.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-client.x86_64 0:1.1.3.3-4.fc20 will be an update --> Processing Dependency: libwsman_client.so.1()(64bit) for package: libvirt-client-1.1.3.3-4.fc20.x86_64 ---> Package libvirt-daemon.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon.x86_64 0:1.1.3.3-4.fc20 will be an update --> Processing Dependency: libwsman_client.so.1()(64bit) for package: libvirt-daemon-1.1.3.3-4.fc20.x86_64 ---> Package libvirt-daemon-driver-interface.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-interface.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-network.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-network.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-nodedev.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-nwfilter.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-qemu.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-secret.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-secret.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-driver-storage.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-driver-storage.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package libvirt-daemon-kvm.x86_64 0:1.1.3.3-3.fc20 will be updated ---> Package libvirt-daemon-kvm.x86_64 0:1.1.3.3-4.fc20 will be an update ---> Package uboot-tools.x86_64 0:2013.10-3.fc20 will be installed --> Processing Dependency: dtc for package: uboot-tools-2013.10-3.fc20.x86_64 --> Running transaction check ---> Package dtc.x86_64 0:1.4.0-2.fc20 will be installed ---> Package libvirt-client.x86_64 0:1.1.3.3-4.fc20 will be an update --> Processing Dependency: libwsman_client.so.1()(64bit) for package: libvirt-client-1.1.3.3-4.fc20.x86_64 ---> Package libvirt-daemon.x86_64 0:1.1.3.3-4.fc20 will be an update --> Processing Dependency: libwsman_client.so.1()(64bit) for package: libvirt-daemon-1.1.3.3-4.fc20.x86_64 --> Finished Dependency Resolution Error: Package: libvirt-client-1.1.3.3-4.fc20.x86_64 (updates-testing) Requires: libwsman_client.so.1()(64bit) Available: libwsman1-2.3.6-8.fc20.x86_64 (fedora) libwsman_client.so.1()(64bit) Installed: libwsman1-2.4.3-1.fc20.x86_64 (installed) ~libwsman_client.so.2()(64bit) Error: Package: libvirt-daemon-1.1.3.3-4.fc20.x86_64 (updates-testing) Requires: libwsman_client.so.1()(64bit) Available: libwsman1-2.3.6-8.fc20.x86_64 (fedora) libwsman_client.so.1()(64bit) Installed: libwsman1-2.4.3-1.fc20.x86_64 (installed) ~libwsman_client.so.2()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [asinha@ankur-laptop Downloads]$ So, it looks like dnf simply says "Nothing to do" when it should say "Error: broken dependencies".
Please read documentation, this is expected behavior. http://akozumpl.github.io/dnf/user_faq.html#why-are-dnf-check-update-packages-not-marked-for-upgrade-in-the-following-dnf-upgrade However it might make sense to document this specific behavior directly in the man page to raise users' attention.
(In reply to Jan Zeleny from comment #4) > However it might make sense to document this specific behavior directly in > the man page to raise users' attention. Just done upstream in 01649a8: https://github.com/akozumpl/dnf/commit/01649a87920dcb4de6d5285c730799f64bfc2d3c
Shouldn't at least debugging mode specify that packages are skipped due to broken dependencies? It'll be really helpful for QA folks that test package updates. In the current scenario, we'll have to run dnf check-update and then dnf update and compare the differences in the package sets to see if any packages are broken.
(In reply to Ankur Sinha (FranciscoD) from comment #6) > Shouldn't at least debugging mode specify that packages are skipped due to > broken dependencies? It'll be really helpful for QA folks that test package > updates. In the current scenario, we'll have to run dnf check-update and > then dnf update and compare the differences in the package sets to see if > any packages are broken. 'dnf upgrade' does not even see the packages that are not installable so can not mark them. use dnf --best upgrade for that. We build DNF so it is helpful to the Fedora users and system administrators. We really would like to help QA teams too but not at the cost of compromising the more common use cases (i.e. the average user does not want to be debugging broken dependencies/using --skip-broken when upgrading system.). Moreover---you can do just what you described above.
(In reply to Ales Kozumplik from comment #7) > (In reply to Ankur Sinha (FranciscoD) from comment #6) > > Shouldn't at least debugging mode specify that packages are skipped due to > > broken dependencies? It'll be really helpful for QA folks that test package > > updates. In the current scenario, we'll have to run dnf check-update and > > then dnf update and compare the differences in the package sets to see if > > any packages are broken. > > 'dnf upgrade' does not even see the packages that are not installable so can > not mark them. use dnf --best upgrade for that. > > We build DNF so it is helpful to the Fedora users and system administrators. The current yum behaviour does not cause any trouble to users and system administrators at all. At least they're aware that a package update is broken and when they ask around, people in the community that know of the issue can help them. What happens when a package set is broken and dnf just keeps saying "Nothing to do"? How will the *user* go about debugging this? All he'll see is that there's nothing wrong, and yet, dnf won't install the package. Since you're making it even more difficult for QA to catch these cases with this move, the probability of such cases slipping into stable states increases (since QA won't catch them at all and the updates will get pushed to stable after 2 weeks when they don't receive *negative* karma) > We really would like to help QA teams too but not at the cost of > compromising the more common use cases (i.e. the average user does not want > to be debugging broken dependencies/using --skip-broken when upgrading > system.). Moreover---you can do just what you described above. No one is going to run dnf check-update followed by dnf update and then check the package lists as a routine QA task. I only ran that progression of commands because I already *knew* that a package update was available yet failed to get dnf to update and went about investigating. Also, I was looking to test a *particular* update that only contained libvirt packages. Would you expect someone to do this when there are 100s of packages in the update? I disagree with your thinking here. You're not really making things easier for users, you're making it more difficult for everyone (not just users or admins) to debug when things go wrong. The skip broken error is informative. Any error is informative. Please do not simply ignore them. Thanks, Warm regards, Ankur
If nothing else, at least any errors or warnings should be shown in debugging mode. If possible, a flag that people can use even. Silently skipping errors isn't a good way to go IMO.
(In reply to Ankur Sinha (FranciscoD) from comment #9) > If nothing else, at least any errors or warnings should be shown in > debugging mode. If possible, a flag that people can use even. Silently > skipping errors isn't a good way to go IMO. I have to disagree. Have you seen how many bugs yum receives because of issues that are actually caused by different components? It causes so much maintenance overhead that we currently have a few hundred bugs in yum, with large portion of them being irrelevant. Don't giving user the information that he actually doesn't require (having the information won't give you anything but a warm feeling that you think you know what's happening) is much better than confusing him. BTW: If you still want the information about broken packages, you can use the --best switch, as documented in the FAQ.
(In reply to Jan Zeleny from comment #10) > (In reply to Ankur Sinha (FranciscoD) from comment #9) > > If nothing else, at least any errors or warnings should be shown in > > debugging mode. If possible, a flag that people can use even. Silently > > skipping errors isn't a good way to go IMO. > > I have to disagree. Have you seen how many bugs yum receives because of > issues that are actually caused by different components? It causes so much > maintenance overhead that we currently have a few hundred bugs in yum, with > large portion of them being irrelevant. Don't giving user the information > that he actually doesn't require (having the information won't give you > anything but a warm feeling that you think you know what's happening) is > much better than confusing him. I thought the idea of a rewrite, amongst other things was that you'd be able to design the software to be able to better incorporate these components, as opposed to yum which had them incrementally added over the years. Anyway, you're upstream and probably know best. If it causes issues, you'll have bugs filed :) > > BTW: If you still want the information about broken packages, you can use > the --best switch, as documented in the FAQ. Yep. Created an alias already. Thanks for your comments, Warm regards, Ankur