From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RhlN6-0004gl-EZ for garchives@archives.gentoo.org; Mon, 02 Jan 2012 17:08:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2341921C03C; Mon, 2 Jan 2012 17:08:10 +0000 (UTC) Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com [209.85.215.181]) by pigeon.gentoo.org (Postfix) with ESMTP id 8C5FC21C32E for ; Mon, 2 Jan 2012 17:06:08 +0000 (UTC) Received: by eaai1 with SMTP id i1so10378257eaa.40 for ; Mon, 02 Jan 2012 09:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=kJYxOHBFyHQSGhPccB3vfyjj++2MbYS8wxmNzuKq1VQ=; b=Fb1o70wmu+nDRItf3XFBnLWodY1/Fe9NFY5CBVbjaUqgbiIeqNk5PAKcNqRx7ODVcZ bmbYIkRWsVBbx/75Vzc55cXK1whaMXE3WAz5f6WLXeU0gQk/CHyVkokUjzkv9VLCCW4p glYMx7qb6oUuE/qnoYfpMhbs80YODh1LqStxQ= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.205.132.148 with SMTP id hu20mr8726179bkc.96.1325523967698; Mon, 02 Jan 2012 09:06:07 -0800 (PST) Received: by 10.204.177.18 with HTTP; Mon, 2 Jan 2012 09:06:07 -0800 (PST) In-Reply-To: <4F01DC67.7070305@orlitzky.com> References: <4F00D521.1030702@orlitzky.com> <4F00DA99.8050502@orlitzky.com> <4F00DEC5.5090500@gmail.com> <4F00E741.6050002@orlitzky.com> <4F01CED2.5090806@libertytrek.org> <4F01D6A2.9000002@orlitzky.com> <4F01DC67.7070305@orlitzky.com> Date: Mon, 2 Jan 2012 12:06:07 -0500 Message-ID: Subject: Re: [gentoo-user] emerge --update behavior From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 06bc1975-c065-4108-9607-25799e31125b X-Archives-Hash: 5c1f941875dd43a885e82ca4109855e8 On Mon, Jan 2, 2012 at 11:33 AM, Michael Orlitzky wr= ote: > 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: >>> >>> =C2=A0dev-php/PEAR-Mail >>> =C2=A0dev-php/PEAR-Mail_Mime >>> =C2=A0dev-php/PEAR-PEAR >>> =C2=A0dev-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=3Dy @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-Ma= il, > 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 fi= le. > If I ever remove dev-php/PEAR-Mail_Mime, depclean will remove PEAR-Mail a= nd > 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) --=20 :wq