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
signature.asc
Description: This is a digitally signed message part
