Description of problem: When clean_requirements_on_remove=0 in /etc/yum.conf all is as expected. Going "yum removes package1 package2 ..." results in yum stating what it's about to do. It of course says that all the targets you explicitly specified will be removed as well as any packages that depend on those targets. These dependent packages are listed in the "Removing for dependencies:" section. However should I set clean_requirements_on_remove=1 in my /etc/yum.conf thats when shit hits the fan. This has nothing to do with the dependency resolver btw which to the best of my knowledge works just fine. My problem has to do with yum poorly explaining what it's about to do before we enter that y character for a given transaction. For example I have both the packages gcc and gcc-c++ installed on my system. Now gcc-c++ depends on gcc. And gcc has dependencies of its own such as cpp. When clean_requirements_on_remove=1 the "Removing for dependencies:" section of the transactions descriptions lists both the dependencies and the dependents of the specified targets in that same section without any distinction between the two. For example: [georgiy@PANTHER ~]$ su -c 'yum remove gcc' Password: ... ========================================================================================================================================================================== Package Arch Version Repository Size ========================================================================================================================================================================== Removing: gcc x86_64 4.7.0-5.fc17 @fedora 32 M Removing for dependencies: binutils x86_64 2.22.52.0.1-10.fc17 @fedora 14 M cloog-ppl x86_64 0.15.11-3.fc17.1 @fedora 183 k cpp x86_64 4.7.0-5.fc17 @fedora 12 M gcc-c++ x86_64 4.7.0-5.fc17 @fedora 13 M gcc-gnat x86_64 4.7.0-5.fc17 @fedora 33 M glibc-devel x86_64 2.15-37.fc17 @fedora 964 k glibc-headers x86_64 2.15-37.fc17 @fedora 2.1 M kernel-headers x86_64 3.4.4-3.fc17 @updates 2.7 M libgnat x86_64 4.7.0-5.fc17 @fedora 3.5 M libgnat-devel x86_64 4.7.0-5.fc17 @fedora 17 M libmpc x86_64 0.9-2.fc17.2 @fedora 113 k libstdc++-devel x86_64 4.7.0-5.fc17 @fedora 7.7 M ppl x86_64 0.11.2-8.fc17 @fedora 5.4 M ppl-pwl x86_64 0.11.2-8.fc17 @fedora 94 k Transaction Summary ========================================================================================================================================================================== Remove 1 Package (+14 Dependent packages) Installed size: 144 M ... See removing gcc will break gcc-c++ and gcc-gnat. That's why they get removed regardless of the value of clean_requirements_on_remove. However I want clean_requirements_on_remove=1 so that unneeded packages don't take up disk space. There's no reason yum shouldn't clean up after itself. The point is in this case I know that the removal of cpp is to clean unneeded cruft and the removal of gcc-c++ is because that package would be broken without gcc. However both cpp and and gcc-c++ are listed in the same way in the "Removing for dependencies:" section. There's a big difference between removing unneeded cruft and removing a package because one might have (possibly accidentally) told yum to remove one of it's dependencies. IN THE LATTER CASE THE USER SHOULD BE CLEARLY TOLD SO IN THE OUTPUT SO THAT THEY UNDERSTAND THE FULL RAMIFICATIONS OF ENTERING THAT Y. HOWEVER YUM MAKES NO DISTINCTION BETWEEN DEPENDENCIES AND REVERSE DEPENDENCIES WHEN WRITING OUT WHAT IT"S GOING TO DO. THAT'S NOT GOOD. I carefully monitor yum's output before pressing that y and I won't do anything too stupid. The best package manager is ALWAYS the human brain. However humans are fallible and many of them including myself would prefer yum warns me that I may be trying to do something stupid. For example I'm not thinking my best at 2AM... Version-Release number of selected component (if applicable): All versions of yum for which clean_requirements_on_remove is a setting How reproducible: Always Steps to Reproduce: 1. Unknowingly go "yum remove <some package which other installed packages depend on and which have other unneeded dependencies which will also be removed due to clean_requirements_on_remove=1>. 2. Look at the "Removing for dependencies:" section which doesn't distinguish in any way between the specified targets, unneeded dependencies, and installed packages which depend on one of the targets you specified for removal. Be unable to easily make this distinction on your own. 3. Enter y and possibly do something you may regret do to yum giving you insufficient information to understand the situation. Actual results: Look at above. Expected results: Yum tells me which packages up for removal are dependents of targets specified to yum remove. Yum tells me which packages are being removed because they are unneeded dependencies. Yum confirms to me the targets I specified explicitly to yum remove. Additional info: Just try it out for particular cases. Like install gcc-c++. Enable clean_requirements_on_remove. Go "yum remove gcc". Have fun distinguishing the dependencies and reverse dependencies in the "Removing for dependencies:" section.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.