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