I think a warning should be added to the -C/--unmerge option like that exists for other things now such as system, profile, and set files. When ever someone goes to remove a dependency of another package. A package they did not merge themselves directly and not brought in via normal means. If someone goes to emerge -C gcc, you get a warning; !!! 'sys-devel/gcc' is part of your system profile. !!! Unmerging it may be damaging to your system. I think portage should generate a similar warning for dependencies. It does not have to say what the dependencies are. Just that the package was not user installed, nor part of the system profile, world, etc. !!! 'sys-devel/gcc' is a dependency of another package on your system !!! Unmerging it may be damaging to your system May also say something like add -v or use -cv to show the dependent packages. This way users will be warned before removing anything they did not install themselves. Just like the warnings that are generated now for other things. This does require a valid world file that is not corrupted or tainted. Thus depends IMHO on bug 624628 Thank you for your consideration of this request!
This makes no sense. There is a reason why '-c' and '-C' are separate options. I know that a lot of people are incorrectly documenting '-C' everywhere but you're supposed to use '-c' unless you *really* know what you're doing. Furthermore, reporting dependency problems without explicitly listing them is a waste of time. Spending all the time on depgraph calculation just to say 'something is wrong, run X to print what it is' makes just no sense. It's basically like this: user runs -C, gets warning, aborts, runs -cv, sees what it is, runs -C again. So three calculations instead of one. What really needs to happen is that people stop using '-C' when they want '-c'. Also, might be useful to make '-c' default-verbose if packages are explicitly listed.
(In reply to Michał Górny from comment #1) > This makes no sense. There is a reason why '-c' and '-C' are separate > options. I know that a lot of people are incorrectly documenting '-C' > everywhere but you're supposed to use '-c' unless you *really* know what > you're doing. If you do not understand the concept, then please do not comment. c-/--depclean will NOT remove stuff from world. It is not a remove package command. It is a clean your system command. YOU should know this! > Furthermore, reporting dependency problems without explicitly listing them > is a waste of time. Spending all the time on depgraph calculation just to > say 'something is wrong, run X to print what it is' makes just no sense. > It's basically like this: user runs -C, gets warning, aborts, runs -cv, sees > what it is, runs -C again. So three calculations instead of one. Again, there is no need for dependency calculation. How are system profile and set packages known when trying to be removed? This is the same but in reverse. If you are not capable of thinking of ways to improve this. Then that is your own handicap. There are many ways I have shown that do not require dependencies. IF you want to go down that route. All you need is 1 dependency not all. All that matters is if any single package still needs the one trying to be removed. Any mention of depgraph calculation has no relevance. > What really needs to happen is that people stop using '-C' when they want > '-c'. Also, might be useful to make '-c' default-verbose if packages are > explicitly listed. What needs to happen is people like you need to understand they are NOT the same and will not perform the same function. It is amazing you do not KNOW this already.... emerge -c package != emerge -C package One will be removed, one will not, if package is in world....
(In reply to William L. Thomson Jr. from comment #2) > emerge -c package != emerge -C package > > One will be removed, one will not, if package is in world.... Actually emerge -c will remove packages from world just fine. # grep gentoolkit /var/lib/portage/world app-portage/gentoolkit # emerge -c gentoolkit Calculating dependencies... done! >>> Calculating removal order... app-portage/gentoolkit selected: 0.4.0 protected: none omitted: none All selected packages: =app-portage/gentoolkit-0.4.0 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Unmerging (1 of 1) app-portage/gentoolkit-0.4.0... Packages installed: 440 Packages in world: 62 Packages in system: 44 Required packages: 440 Number removed: 1 * GNU info directory index is up-to-date. # grep gentoolkit /var/lib/portage/world # It will only not remove it if it is a dependency for something else.
(In reply to Paul Varner from comment #3) > (In reply to William L. Thomson Jr. from comment #2) > > emerge -c package != emerge -C package > > > > One will be removed, one will not, if package is in world.... > > Actually emerge -c will remove packages from world just fine. Ok I stand corrected, but will it remove say sys-devel/gcc > It will only not remove it if it is a dependency for something else. Or not residing in something else, profile or set.
FYI this came up per another users mention. I did not bring up the idea of removing packages. Others did in the sets discussion. https://archives.gentoo.org/gentoo-dev/message/4ba8307a9dd5561cc1859a8c9546807a They were concerned with fail safes. It was discussed and mentioned they did get a warning from gcc that they added to a set, and were removing. I simply thought there could be other uses of said warning to protect users. I myself have moved away from having anything in world at all. I use profiles, in my repo, not per system in /etc/portage/profile. Thus this is all for others not me.
Actually they were the second person to suggest such https://archives.gentoo.org/gentoo-dev/message/201cc1e7b5b878e3b28c3da1a41819e2 For everyone trying to correct me saying I should use -c vs -C. It was not me even using either in the first place. I did not bring it up in the discussion. I simple was entertaining others objections. Which turned into others saying I am not using this or that correctly. When I am not even doing the stuff others are which would have a need for such. Really interesting how others can stray things so far from the original point. It clearly seems many, not including myself want to use -c/--unmerge. Thus they brought it up on list in the sets thread.
Sorry for dup, not sure how that happened? (In reply to William L. Thomson Jr. from comment #6) > Actually they were the second person to suggest such > > https://archives.gentoo.org/gentoo-dev/message/ > 201cc1e7b5b878e3b28c3da1a41819e2 > Interesting how no one replied to that saying you should use -c vs -C.... Like many have said to me... Good stuff! That people should not use -C makes their entire argument against sets completely moot. This is really funny stuff!!! :)
Firstly, please do not reopen bugs that have been closed by the assignee. If you disagree with my decision, feel free to comment but leave the decision on reopening to us (the Portage team). Secondly, please restrain from offensive comments and shouting. This does not help anyone. Thirdly, please stay on topic.
(In reply to Michał Górny from comment #8) > Firstly, please do not reopen bugs that have been closed by the assignee. If > you disagree with my decision, feel free to comment but leave the decision > on reopening to us (the Portage team). > > Secondly, please restrain from offensive comments and shouting. This does > not help anyone. > > Thirdly, please stay on topic. Stop commenting on things the person has specifically multiple times requested you stop. This is assigned to a team not a person. Let others comment. Please again refrain from commenting on anything I am involved with. It is very simple. If others want to close this, that is their choice after a discussion. If you do not want to be part of this, then stay out of it. Stop closing things you are personally not interested in and having your personal say as the final word.
(In reply to William L. Thomson Jr. from comment #9) This is really inappropriate behavior for a bug tracker, but I suppose you already know that.
(In reply to Greg Kubaryk from comment #10) > (In reply to William L. Thomson Jr. from comment #9) > This is really inappropriate behavior for a bug tracker, but I suppose you > already know that. A discussion took place on list prior to opening bugs. Others should not be commenting here. I am looking to discuss and interact with the main portage developers. Others are just getting in the way, causing problems. Which your comment is another that has no relevance on a technical bug report. Which would be zac, vapier, or maybe dol-sen. https://github.com/gentoo/portage/graphs/contributors No one else really need comment. Its been discussed on list. This is now about the technical aspects of implementation.
(In reply to William L. Thomson Jr. from comment #2) > Again, there is no need for dependency calculation. > > How are system profile and set packages known when trying to be removed? We just check if the package is matched by any of the atoms in the package set, which is a relatively inexpensive operation. > This is the same but in reverse. If you are not capable of thinking of ways > to improve this. Then that is your own handicap. There are many ways I have > shown that do not require dependencies. > > IF you want to go down that route. All you need is 1 dependency not all. All > that matters is if any single package still needs the one trying to be > removed. > Any mention of depgraph calculation has no relevance. In order to do this, you have to evaluate the dependencies of *all* installed packages, and at that point the expense is very close to calculating a whole depgraph like --depclean does.
In comparison to package sets, it's trickier to check reverse dependencies of packages due to || deps. For example, if you have || ( package-A package-B ), then --depclean might be able to see that it should remove package-A, and it should keep package-B because something requires it unconditionally.
I was thinking build a package list comprised of world, system, and any use sets. If the package trying to be removed is not in that list, provide a warning that it was not found in any of those. Thus it maybe a dependent package. It already provides warnings for packages in those. It must be created some package lists and comparing the package the user is trying to remove against that. This would just be including 1 more package list file, /var/lib/portage/world. That does not require complex reverse dependency traversal. It should be pretty quick to parse /var/lib/portage/world along with say profile/packages, etc. It seems it is already reading /var/lib/portage/world_sets. Since that is the only place user selected sets are recorded. This would just be parsing another file like that. Looking at unmerge.py, seems /var/lib/portage/world contents could be added to maybe realsyslist. https://github.com/gentoo/portage/blob/master/pym/_emerge/unmerge.py#L67 Then it is just a matter of marking it in some way that the error message changes. Though it could stick with the current message, as it has the same meaning.
