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 1PoPUI-0004qv-EE for garchives@archives.gentoo.org; Sun, 13 Feb 2011 00:06:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EBFD0E0A0B for ; Sun, 13 Feb 2011 00:06:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id DD256E0952 for ; Sat, 12 Feb 2011 23:43:39 +0000 (UTC) Received: from [192.168.22.4] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 5646E1B4031 for ; Sat, 12 Feb 2011 23:43:39 +0000 (UTC) Message-ID: <4D571B19.3010800@gentoo.org> Date: Sat, 12 Feb 2011 15:43:21 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20110110 Lightning/1.0b3pre Thunderbird/3.1.7 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] About how to make compilation think some files are missing References: <1297525846.6230.40.camel@localhost.localdomain> In-Reply-To: <1297525846.6230.40.camel@localhost.localdomain> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: cabfd57ff2dd21cc90335af3de4c41c7 On 02/12/2011 07:50 AM, Pacho Ramos wrote: > This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets > stabilized, depclean will try to remove glitz, but removing glitz will > break a lot of apps, needing to rebuild them and, until then, having a > partially broken system. > > I then thought on running revdep-rebuild --library libglitz-glx.so.1 > BEFORE removing glitz (to prevent breakage), but later I remembered it > wouldn't work as rebuilt packages would link again against > libglitz-glx.so.1. > > Then, my idea would the following: > > Would be nice if I could tell portage to make compilation think > libglitz-glx.so.1 is not present in real system (maybe sandbox could > prevent its readability inside build environment), and then, I could run > "revdep-rebuild --library libglitz-glx.so.1" before removing glitz and > affected apps would not link to it, allowing me to safely remove glitz > later without having had a broken system at any time. > > What do you think? Thanks Ideally, the build system(s) involved would have options to explicitly disable linking against the deprecated library. Barring that possibility, something like your sandbox idea seems like the second-best solution. On par with the the sandbox idea would be to migrate the deprecated library to a directory which is not included in the default library search path, and to use a global LD_LIBRARY_PATH setting so that your apps can find it until they are rebuilt. Then you could execute your rebuilds in an environment with a modified LD_LIBRARY_PATH value that excludes the path of the deprecated library. -- Thanks, Zac