| 1 |
On Sat, May 10 2014, Alan McKinnon wrote: |
| 2 |
|
| 3 |
> On 09/05/2014 23:34, gottlieb@×××.edu wrote: |
| 4 |
>> On Fri, May 09 2014, gottlieb@×××.edu wrote: |
| 5 |
>> |
| 6 |
>>> On Fri, May 09 2014, Alan McKinnon wrote: |
| 7 |
>>> |
| 8 |
>>>> There's a brute force method. All the nvidia files listed below are now |
| 9 |
>>>> orphaned, so you should be able to delete them and let revdep-rebuild |
| 10 |
>>>> fix anything remaining. |
| 11 |
>>> |
| 12 |
>>> I see. This encouraged me to look at |
| 13 |
>>> /var/lib/portage/preserved_libs_registry, whose contents is |
| 14 |
>>> |
| 15 |
>>> "x11-drivers/nvidia-drivers:0": [ |
| 16 |
>>> "x11-drivers/nvidia-drivers-334.21-r3", |
| 17 |
>>> "12161", |
| 18 |
>>> [ |
| 19 |
>>> "/usr/lib64/libnvidia-glcore.so.334.21", |
| 20 |
>>> "/usr/lib64/libnvidia-tls.so.334.21", |
| 21 |
>>> "/usr/lib32/libnvidia-glsi.so.334.21", |
| 22 |
>>> "/usr/lib32/opengl/nvidia/lib/libGL.so.334.21", |
| 23 |
>>> "/usr/lib64/libnvidia-glsi.so.334.21", |
| 24 |
>>> "/usr/lib32/opengl/nvidia/lib/libEGL.so.334.21", |
| 25 |
>>> "/usr/lib64/opengl/nvidia/lib/libGL.so.334.21", |
| 26 |
>>> "/usr/lib32/libnvidia-tls.so.334.21", |
| 27 |
>>> "/usr/lib64/opengl/nvidia/lib/libEGL.so.334.21", |
| 28 |
>>> "/usr/lib32/libnvidia-glcore.so.334.21", |
| 29 |
>>> "/usr/lib64/opengl/nvidia/lib/libGL.so.1", |
| 30 |
>>> "/usr/lib64/opengl/nvidia/lib/libEGL.so.1", |
| 31 |
>>> "/usr/lib32/opengl/nvidia/lib/libGL.so.1", |
| 32 |
>>> "/usr/lib32/opengl/nvidia/lib/libEGL.so.1" |
| 33 |
>>> ] |
| 34 |
>>> ] |
| 35 |
>>> } |
| 36 |
>>> |
| 37 |
>>> So I guess this means that all the orphans come from nvidia-drivers. |
| 38 |
>>> So I am initially not unmerging/remerging emul-linux-x86. |
| 39 |
>>> That is my plan will be |
| 40 |
>>> |
| 41 |
>>> move orphaned files listed above to a holding area |
| 42 |
>>> let revdep-rebuild do its thing |
| 43 |
>>> wait 30 days |
| 44 |
>>> delete the holding bin |
| 45 |
>>> |
| 46 |
>>> Thanks for explaining. |
| 47 |
>>> allan |
| 48 |
>> |
| 49 |
>> Before I mess up let me ask if the contents of preserved_libs_registry |
| 50 |
>> shown above will be cleaned by the emerges triggered by revdep-rebuild |
| 51 |
>> or if I am supposed to modify that file myself when I remove the |
| 52 |
>> orphans. |
| 53 |
>> |
| 54 |
>> thanks, |
| 55 |
>> allan |
| 56 |
> |
| 57 |
> |
| 58 |
> I'm not entirely certain how portage maintains preserved_libs_registry |
| 59 |
> and when it gets modified (I suspect the exact answer has changed over |
| 60 |
> time) so my recommendation is to leave the file alone unless you are |
| 61 |
> forced to modify it. |
| 62 |
> |
| 63 |
> I've done that a few times in the past to fix issues like you ar dealing |
| 64 |
> with - it's a rather blunt weapon though. Having said that, it's not |
| 65 |
> especially dangerous. preserved_libs_registry is really just a bunch of |
| 66 |
> flags of stuff to be rebuilt, so if you do mess it up, a round of emerge |
| 67 |
> world && revdep-rebuild gets things consistent again, it just takes some |
| 68 |
> time and cpu cycles |
| 69 |
|
| 70 |
Thanks. I moved the orphaned files. revdep-rebuild and emerge world |
| 71 |
had nothing to say (recall I already ran emerge @preserved_rebuild). |
| 72 |
In a month tmpwatch will kill the orphaned files for good. |
| 73 |
|
| 74 |
thanks again. |
| 75 |
allan |
Archives