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 1Poait-00044e-U8 for garchives@archives.gentoo.org; Sun, 13 Feb 2011 12:06:40 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6613EE0893 for ; Sun, 13 Feb 2011 12:06:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D6EC3E07BD for ; Sun, 13 Feb 2011 11:54:31 +0000 (UTC) Received: from [192.168.1.201] (23.151.222.87.dynamic.jazztel.es [87.222.151.23]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id CD5401B4102 for ; Sun, 13 Feb 2011 11:54:30 +0000 (UTC) Subject: Re: [gentoo-portage-dev] About how to make compilation think some files are missing From: Pacho Ramos To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <4D571B19.3010800@gentoo.org> References: <1297525846.6230.40.camel@localhost.localdomain> <4D571B19.3010800@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VwOnDYpntblg+7EK36VQ" Date: Sun, 13 Feb 2011 12:54:26 +0100 Message-ID: <1297598066.17011.1.camel@localhost.localdomain> 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 X-Mailer: Evolution 2.32.2 X-Archives-Salt: X-Archives-Hash: 4dd8acdb95c1792ee19c399fc129bb29 --=-VwOnDYpntblg+7EK36VQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El s=C3=A1b, 12-02-2011 a las 15:43 -0800, Zac Medico escribi=C3=B3: > 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. > >=20 > > 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. > >=20 > > Then, my idea would the following: > >=20 > > 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 ru= n > > "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. > >=20 > > What do you think? Thanks >=20 > Ideally, the build system(s) involved would have options to explicitly > disable linking against the deprecated library. >=20 > Barring that possibility, something like your sandbox idea seems like > the second-best solution. >=20 > 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. Didn't think about that last LD_LIBRARY_PATH option, looks easier for now. Thanks --=-VwOnDYpntblg+7EK36VQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAk1XxnIACgkQCaWpQKGI+9SpAQCfQj926Yy5tzm/WyCse0rrbrKa Io4An2Q8UaMXiKGqlDMv2msS4VZKW91k =qgVb -----END PGP SIGNATURE----- --=-VwOnDYpntblg+7EK36VQ--