Re: [gentoo-portage-dev] About how to make compilation think some files are missing

[Pacho Ramos]

El sáb, 12-02-2011 a las 15:43 -0800, Zac Medico escribió:
> 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.

Didn't think about that last LD_LIBRARY_PATH option, looks easier for
now. Thanks