Description of problem: When doing yum install foo or yum erase bar, yum explicitly lists which packages are installed or removed on user request (Installing / Removing), and separately lists those that need to be installed as dependencies (Installing for Dependencies) or those that additionally need to be removed because they depend on a package to be removed. dnf does not print that information. It's bad especially when removing packages, as when multiple packages are to be removed, it's easy to miss a dependency that got silently added to the list. Version-Release number of selected component (if applicable): dnf-1.0.1-2.fc22.noarch Steps to Reproduce: # yum-deprecated install light-gtk3-theme ... Installing: light-gtk3-theme noarch 14.04-3.20150410bzr434.fc22 updates 190 k Installing for dependencies: gtk-unico-engine x86_64 1.0.3-0.5.20140109bzr152.fc22 fedora 26 k # dnf install light-gtk3-theme ... Installing: gtk-unico-engine x86_64 1.0.3-0.5.20140109bzr152.fc22 fedora 26 k light-gtk3-theme noarch 14.04-3.20150410bzr434.fc22 updates 190 k # yum-deprecated erase ktuberling ... Removing: ktuberling x86_64 15.04.3-1.fc22 installed 7.2 M Removing for dependencies: kdegames noarch 6:4.14.3-1.fc22 @fedora 0.0 # dnf erase ktuberling ... Removing: kdegames noarch 6:4.14.3-1.fc22 @System 0 ktuberling x86_64 15.04.3-1.fc22 @System 7.2 M
dnf erase should also separately report autoremoved dependencies.
Let me just note that DNF was never meant to be a drop in replacement of YUM and thus since it never printed the information, it's incorrect to mark this as a regression.
You can of course re-keyword and re-prioritize this bug as you see fit. While dnf never printed that information and hence lack of it is technically not a dnf regression by itself, it is likely to be seen as regression for anyone upgrading from older Fedora versions with yum, given that dnf is installed as yum replacement to which yum command now redirects. Regression or not, the information printed by yum is useful and it would be really nice to have it printed by dnf as well.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
DNF improved with dnf-2.5x that is available for rawhide, and Fedora 26. If we install dependencies we mark them as ``Installing dependencies:``. If we remove unused dependencies we mark them as ``Removing unused dependencies:``. I hope that it is exactly what was requested.
The "Removing unused dependencies" suggests that section would list packages that are required by the package being uninstalled and that are getting auto-removed. How does it handle the ktuberling/kdegames example from comment 0? I.e. the situation when the package to be uninstalled is required by another installed packages, so removal of that other package is also forced. This is not the auto-remove case.
TestA requires TestB: sudo dnf remove TestB Dependencies resolved. ============================================================================================================ Package Arch Version Repository Size ============================================================================================================ Removing: TestA noarch 1.0.0-2 @home_jmracek_Projects_ci-dnf-stack_dnf-docker-test_repo_upgrade_6 0 TestB noarch 1.0.0-2 @home_jmracek_Projects_ci-dnf-stack_dnf-docker-test_repo_upgrade_6 0 Transaction Summary ============================================================================================================ Remove 2 Packages Freed space: 0 Is this ok [y/N]: That means that we do not mark them as yum as removed dependency.
Thank you for the quick check / confirmation. Should I open a separate bug for that, or do you prefer to re-open this bug?
I will try to find out a solution for the remaining problem. But if you would like to help, please can you provide a statement that should mark the situation. Something like: Remove due to requires (But this I don't like).
I created a patch that should provide solution (https://github.com/rpm-software-management/dnf/pull/873). But still the statements has to be improved.
dnf-2.6.3-1.fc26 dnf-plugins-extras-2.0.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4813633f96
dnf-2.6.3-1.fc26, dnf-plugins-extras-2.0.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4813633f96
dnf-2.6.3-1.fc26, dnf-plugins-extras-2.0.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
This comment from 2015 made my day: "Let me just note that DNF was never meant to be a drop in replacement of YUM" I ended up here because I just saw this: $ sudo dnf remove qemu-img ... Removing unused dependencies: ... hexedit x86_64 1.2.13-9.fc26 @@commandline 64 k How could hexedit depend on qemu? $ rpmdep -dot hexedit.dot hexedit $ dot -Tpng hexedit.dot -o hexedit.png But I still don't see.
(BTW, I know that this issue is closed and I am actually somewhat off-topic, as I question rpm dependencies. But I do not want to open a new ticket for qemu dependencies.)
Please can you run "sudo dnf autoremove" before you try to remove qemu-img. And try to remove hexedit before removal of gemu... Also hexedit could be weak dep, but don't think so. But if you want to really get clue, better to open the new issue.