On Mon, Jan 2, 2012 at 11:33 AM, Michael Orlitzky <mich...@orlitzky.com> wrote: > On 01/02/2012 11:16 AM, Michael Mol wrote: >>> >>> >>> Fine for your home PC, doesn't cut it on servers. I have the following in >>> one of my world files: >>> >>> dev-php/PEAR-Mail >>> dev-php/PEAR-Mail_Mime >>> dev-php/PEAR-PEAR >>> dev-php/PEAR-Structures_Graph >>> >>> which of those do I want? At least one of them was installed to support a >>> customer's custom PHP application. Maybe all of them were and they all >>> belong in world. No one knows, this server is older than the current >>> --update behavior. >>> >>> So which ones can I remove? >>> >>> Solutions involving time travel and/or losing customers will be >>> disqualified. >> >> >> Make a backup copy of your world file. >> >> 1a. Remove those four lines. >> 2a. emerge -p --depclean >> 3a. Did any of those show up in the to-be-removed set? Add them back. >> >> Alternately: >> 1b. emerge -pev --tree --with-bdeps=y @world >> 2b Find those packages in the output. The tree form of the display >> will help you see if anything is depending on them. >> 3b. If anything is depending on them, you should be able to safely >> remove them from your world file. I'd follow up with the 1a, 2a, 3a >> solution to be sure. >> > > Sorry, but these won't work. > > Let's say that dev-php/PEAR-Mail_Mime has a dependency on dev-php/PEAR-Mail, > but I have a customer who needs dev-php/PEAR-Mail for a contact form. > > Following your process, I would remove dev-php/PEAR-Mail from my world file. > If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail and > break the guy's site.
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. 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) -- :wq
