On Mon, Jan 2, 2012 at 12:39 PM, Michael Orlitzky <mich...@orlitzky.com> wrote: > On 01/02/12 12:06, Michael Mol wrote: >> >> That's the purpose of the "emerge -p" step. Presumably, you would see >> that there's a package in the list that you're not comfortable with >> removing, you'd decide you didn't want it removed, and you'd add it >> back to your world set. > > Yeah, I'm not sure I can remove any of them. The only way I see to > determine what's necessary at this point is to remove it and see if > stuff breaks. > > >> If you're not comfortable removing *any* package that's in your world >> set, then, no, there's no way to tell the difference. From this point >> forward, your best bet is to modify EMERGE_DEFAULT_OPTS to reflect the >> safest practice for your environment. And start keeping a list of >> packages installed to meet customers' requests. Portage apparently >> supports your desired workflow, but it needs to be set up for it. >> >> As to recovering from your current scenario...there might be some way >> to watch your apache processes to identify which files get used over a >> three-month span, from that list derive a list of which packages were >> used, and from *that* list, derive a list of which packages weren't >> used. (Or make an ebuild explicitly identifying the utilized >> dependencies, and let depclean handle the rest) > > That's probably more work than copying everything to another box, > emptying the world file, and adding things back until stuff works. > > Either way the current situation is "you're kinda screwed" which is why > I proposed avoiding it in the future (for others, too) by fixing --update.
I hope you don't take this as a kind of disrespect, but this really feels more like administrator error than tool error. As someone else remarked, it's portage's job to do what you tell it to do; you point the gun, pull the trigger, it delivers the projectile. The biggest bug I can see in this whole mess is that the man page might stand some editing for clarity. -- :wq
