When you enter 'emerge -C <pkg>' & <pkg> satisfies a virtual, Portage issues a warning, even when there is another installed package which also satisfies the virtual. Eg if I have Vim installed, which satisfies virtual/editor , & I try to unmerge Nano, which also satisfies that virtual, Portage warns * This action can remove important packages! * In order to be safer, use `emerge -pv --depclean <atom>` Instead of this behaviour, Portage should check the virtual's ebuild, which lists the packages which satisfy it, & check whether another package which satisfies it is also installed, in which case it should not issue a warning. It should issue a warning only if the last package satisfying the virtual is about to be unmerged. The present behaviour is misleading & the warning inaccurate. The extra work by Portage in checking the list will not occur often & should be unnoticeable.
(In reply to Philip Webb from comment #0) > When you enter 'emerge -C <pkg>' & <pkg> satisfies a virtual, Portage issues > a warning, even when there is another installed package which also satisfies > the virtual. > * This action can remove important packages! > * In order to be safer, use `emerge -pv --depclean <atom>` No, it _always_ says that. > Instead of this behaviour, Portage should check the virtual's ebuild, So the current entirely generic: if action == 'unmerge' msg = 'This action can remove [...]' should be replaced with complex code that handles (many) different cases?
You can also set --quiet or --quiet-unmerge-warn to inhibit this message.
While I was about to dismiss this as "duh, -C is an unmerge without dep checks, it always prints a message about being unsafe", I think what he's trying to report is-- When using emerge --depclean (-c), if there is a virtual in @system where 2 installed packages can satisfy it, and depclean deems one "unneeded", it does still print a big scary warning. I personally believe that this warning is unnecessary, but that's up to debate probably: # emerge --depclean --pretend * Always study the list of packages to be cleaned for any obvious * mistakes. Packages that are part of the world set will always * be kept. They can be manually added to this set with * `emerge --noreplace <atom>`. Packages that are listed in * package.provided (see portage(5)) will be removed by * depclean, even if they are part of the world set. * * As a safety measure, depclean will not remove any packages * unless *all* required dependencies have been resolved. As a * consequence, it is often necessary to run `emerge --update * --newuse --deep @world` prior to depclean. Calculating dependencies... done! >>> Calculating removal order... >>> These are the packages that would be unmerged: !!! 'app-editors/nano' (virtual/editor) is part of your system profile. !!! Unmerging it may be damaging to your system. app-editors/nano selected: 2.3.2-r1 protected: none omitted: none All selected packages: app-editors/nano-2.3.2-r1 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Packages installed: 879 Packages in world: 100 Packages in system: 44 Required packages: 878 Number to remove: 1 #
Sorry for confusing 2 different, but related, problems. (1) -C : the warning msg is misleading : if it is indeed always dangerous to use this flag, why is it retained as part of Portage ? If not -- and my successful removal of Nano shows it is not always dangerous -- , the warning needs amending. It should say eg "WARNING ! -- don't use this flag unless you have previously tested the result with 'emerge -cpv <pkg>' & satisfied yourself that no harm to your system will result". (2) -c : this is where the behaviour needs fine-tuning. At present, it refuses to unmerge a package which satisfies a virtual, even when there is another package installed which also satisfies the same virtual. This forces the user to force the issue with 'emerge -C <pkg>', which is best avoided if possible. When Portage is asked to unmerge such a package, it should itself check whether there is another package installed to keep the virtual satisfied & if so, allow the unmerge to go ahead without further ado. Only if the requested unmerge removes the sole (last) package satisfying a virtual should Portage refuse. In the latter case, it should give an accurate warning, eg "<pkg> is the only package installed to satisfy <virtual>. If you unmerge it, you are likely to damage your system". At present, Portage tells the user that to remove Nano will damage his system, which is not true if he has eg Vim installed as well. It says : !!! 'app-editors/nano' (virtual/editor) is part of your system profile. That's not true : 'virtual/editor' is part of my system profile & it is satisfied by Vim. This is demonstrated by the fact that I unmerged Nano & still have a perfectly viable installation.
"portageq expand_virtual / virtual/editor" seems to use different logic than depclean when evaluating this virtual. If a user has app-editors/vim in world and app-editors/nano installed but not in world, portageq will say that nano is the virtual provider, but depclean will say vim is enough and nano can be removed.
(In reply to Philip Webb from comment #4) > Sorry for confusing 2 different, but related, problems. > > (1) -C : the warning msg is misleading : if it is indeed always dangerous to > use this flag, why is it retained as part of Portage ? If not -- and my > successful removal of Nano shows it is not always dangerous -- , the warning > needs amending. It should say eg "WARNING ! -- don't use this flag unless > you have previously tested the result with 'emerge -cpv <pkg>' & satisfied > yourself that no harm to your system will result". -C exists for the cases where one wants to forcibly remove a package, regardless of whether it's a good idea. It is indeed dangerous to use it if you don't know what you're doing, because you can remove things that break other packages or your entire system. > (2) -c : this is where the behaviour needs fine-tuning. At present, it > refuses to unmerge a package which satisfies a virtual, even when there is > another package installed which also satisfies the same virtual. This > forces the user to force the issue with 'emerge -C <pkg>', which is best > avoided if possible. When Portage is asked to unmerge such a package, it > should itself check whether there is another package installed to keep the > virtual satisfied & if so, allow the unmerge to go ahead without further > ado. Only if the requested unmerge removes the sole (last) package > satisfying a virtual should Portage refuse. > In the latter case, it should give an accurate warning, eg "<pkg> is the > only package installed to satisfy <virtual>. If you unmerge it, you are > likely to damage your system". > > At present, Portage tells the user that to remove Nano will damage his > system, which is not true if he has eg Vim installed as well. It says : > > !!! 'app-editors/nano' (virtual/editor) is part of your system profile. > > That's not true : 'virtual/editor' is part of my system profile & it is > satisfied by Vim. This is demonstrated by the fact that I unmerged Nano & > still have a perfectly viable installation. Please provide a concrete example of portage refusing to uninstall a package that satisfies a virtual that can be satisfied by another installed package. As Ben's output shows, portage is more than happy to remove app-editors/nano, as virtual/editor is satisfied by another package as well. The warning makes sense, because if you don't know what you're doing, you probably shouldn't remove nano. If you do know what you're doing (or think you do), you'll just ignore it anyway. (In reply to Ben Kohler from comment #5) > "portageq expand_virtual / virtual/editor" seems to use different logic than > depclean when evaluating this virtual. If a user has app-editors/vim in > world and app-editors/nano installed but not in world, portageq will say > that nano is the virtual provider, but depclean will say vim is enough and > nano can be removed. My guess would be that expand_virtual takes the first package listed that satisfies the virtual, rather than the best one. Nano is first in the list, so it shows up first in expand_virtual.
(In reply to dwfreed from comment #6) > -C exists for the cases where one wants to forcibly remove a package, > regardless of whether it's a good idea. It is indeed dangerous to use it if > you don't know what you're doing, because you can remove things that break > other packages or your entire system. Yes, that's well understood, so Portage should not force a user to use it, if there is another viable alternative. At present, there is no alternative, because of the behavioural glitch which occurs with '-c'. That behaviour needs to be changed, so that users are not forced to rely on '-C'. > Please provide a concrete example of portage refusing to uninstall a package > that satisfies a virtual that can be satisfied by another installed package. > As Ben's output shows, portage is more than happy to remove > app-editors/nano, as virtual/editor is satisfied by another package as well. Only if the user uses '-C'. The refusal to uninstall when using '-c' is described carefully in Comment 4 : that's the behaviour which needs changing. > The warning makes sense, because if you don't know what you're doing, you > probably shouldn't remove nano. If you do know what you're doing (or think > you do), you'll just ignore it anyway. How does a user know whether he knows what he's doing (smile) ? The question is whether Nano cb safely removed : the answer is 'yes' provided there's another editor installed which satisfies the virtual. That question sb answered by Portage, not left to the user to find out for himself. > My guess would be that expand_virtual takes the first package listed > that satisfies the virtual, rather than the best one. > Nano is first in the list, so it shows up first in expand_virtual. Guesses have no place in resolving bug reports.
No need to get argumentative and adversarial, we're trying to help figure out how to resolve this. But since you really want this resolved, here ya go. *** This bug has been marked as a duplicate of bug 375115 ***
