| 1 |
On 02/12/2011 07:50 AM, Pacho Ramos wrote: |
| 2 |
> This comes from glitz removal (bug #330397), as soon as cairo-1.10 gets |
| 3 |
> stabilized, depclean will try to remove glitz, but removing glitz will |
| 4 |
> break a lot of apps, needing to rebuild them and, until then, having a |
| 5 |
> partially broken system. |
| 6 |
> |
| 7 |
> I then thought on running revdep-rebuild --library libglitz-glx.so.1 |
| 8 |
> BEFORE removing glitz (to prevent breakage), but later I remembered it |
| 9 |
> wouldn't work as rebuilt packages would link again against |
| 10 |
> libglitz-glx.so.1. |
| 11 |
> |
| 12 |
> Then, my idea would the following: |
| 13 |
> |
| 14 |
> Would be nice if I could tell portage to make compilation think |
| 15 |
> libglitz-glx.so.1 is not present in real system (maybe sandbox could |
| 16 |
> prevent its readability inside build environment), and then, I could run |
| 17 |
> "revdep-rebuild --library libglitz-glx.so.1" before removing glitz and |
| 18 |
> affected apps would not link to it, allowing me to safely remove glitz |
| 19 |
> later without having had a broken system at any time. |
| 20 |
> |
| 21 |
> What do you think? Thanks |
| 22 |
|
| 23 |
Ideally, the build system(s) involved would have options to explicitly |
| 24 |
disable linking against the deprecated library. |
| 25 |
|
| 26 |
Barring that possibility, something like your sandbox idea seems like |
| 27 |
the second-best solution. |
| 28 |
|
| 29 |
On par with the the sandbox idea would be to migrate the deprecated |
| 30 |
library to a directory which is not included in the default library |
| 31 |
search path, and to use a global LD_LIBRARY_PATH setting so that your |
| 32 |
apps can find it until they are rebuilt. Then you could execute your |
| 33 |
rebuilds in an environment with a modified LD_LIBRARY_PATH value that |
| 34 |
excludes the path of the deprecated library. |
| 35 |
-- |
| 36 |
Thanks, |
| 37 |
Zac |
Archives