On Tue, 11 Jul 2017 14:32:27 -0700 Daniel Campbell wrote: > > I understand where you're coming from, I just thought to give a few > tips to make life a bit easier for you since it works out pretty well > for myself. I think your idea has merit, just unsure of where the > functionality goes, since I'm not a Portage developer. I have been using the -1 option myself for some time. I have also moved away from having anything in world file. I have my own profiles and such. Just not committed to my public overlay yet. This is mostly for others. I do what ever I need directly for myself if it really becomes an issue for me. But I appreciate the thought! > I think the hard part of implementing this will be detecting whether a > command-line-given package is (a) in a set/profile/world and (b) part > of a dependency tree (i.e. shouldn't be removed). I do not think it will be that complex. It already does this now for system, world, and set files. It must be looking at files already. Having it look at say /var/lib/world is just another file/location. > -c already traverses the dependency tree. This one message may mean > iterating through the list of candidate packages and comparing them > against a set/profile/world *per package*, unless the vdb/cache makes > this lookup cheap in terms of cycles. The message would be helpful, > though again, eix-test-obsolete might be the right tool to build that > feature into. I'd be interested in following the bug discussion, if > you've already filed it. The looking at say world file is more an issue for -C than -c. -c knows there are deps. Thus all it needs is an additional minimal message. It already says to see deps use -v. It just does not say, why it took no action. But actually now that I looked at -c, it is completely wrong. I should have caught that sooner. -c does not remove a package, it just removes its deps. -c == --depclean. It is not the same as -C, which is remove a package directly. --unmerge (-C) Not even sure why anyone suggested -c. That explains why I use -C and not -c, but I do use --depclean. This whole thread and topic really got sidetracked big time with -c vs -C. -c should never be mentioned. I was about to file a bug when I noticed such. emerge -c gcc, would never remove gcc, only run depclean emerge -C will remove gcc > If you're really interested in the message from -C, it could be done > by checking the argument list for packages in sets or profiles. But > it's going to incur similar overhead that -c has because it > necessarily has to check some sort of list before producing the > message. Yes this is just about -C, and as stated previously. Other stuff already hits files, this is not different really. > I do not think this message belongs in -C output, however; -C is > intentionally meant for operations where you don't care what happens > to the dependency tree Not true, as I have shown, -C will warn on removing system, world, and set packages. -C will NOT worn on dependencies, which it should. Using the world file and others to know if a package is a dep or in one of those files. > Please don't interpret this e-mail as aggressive or dismissive. I'm > simply trying to offer explanation and guidance to help you make this > happen. It's clear that you care about it, so I'm sure there's a way > for this to go forward. I do not, long as it is not insulting which it does not contain anything of the sort. Though the discussion or mention of -c/--depclean is really off topic. That confused and side tracked things. -- William L. Thomson Jr.