On Fri, May 09 2014, Alan McKinnon wrote:

> On 09/05/2014 14:50, gottl...@nyu.edu wrote:
>> I am switching a system from nvidia-drivers to nouveau.  I changed the
>> entries in make.conf and did emerge --depclean nvidia-drivers.
>> 
>> One result was about a dozen packages to @preserved-rebuild, including
>> two webkit-gtk and libreoffice (so hours to rebuild).
>> 
>> The overnight emerge @preserved-rebuild finished without error, but at
>> the end announced that I again needed to emerge about a dozen packages,
>> again including the two webkit-gtk versions and libreoffice.
>> 
>> The full output (see below) mentions several nvidia files.
>> 
>> How do I break this cycle?
>
> Basically what's happening is portage sees things that used to use the
> old nvidia GL files still want them somehow, so it's keeping those files
> around. Presumably, when packages like libreoffice are rebuilt, they
> will link to the new files provided by nouveau, portage will pick this
> up and release the old files.
>
> For various reasons this doesn't always work out. Consumer apps are not
> always diligent about how they seek libs to link to, and portage can't
> deal with this.
>
> There's a brute force method. All the nvidia files listed below are now
> orphaned, so you should be able to delete them and let revdep-rebuild
> fix anything remaining. You also have stuffs from emul-linux in there,
> so I'd suggest this:
>
> unmerge emul-linux-x86-opengl
> delete orphaned files
> revdep-rebuild and let it do what it wants
> remerge emul-linux-x86-opengl back
>
> Sometimes the portage preserved-rebuild magic doesn't have enough magic,
> so you have to resort to the old manual ways. this looks like one of
> those times

I see.  This encouraged me to look at
/var/lib/portage/preserved_libs_registry, whose contents is

    "x11-drivers/nvidia-drivers:0": [
        "x11-drivers/nvidia-drivers-334.21-r3",
        "12161",
        [
            "/usr/lib64/libnvidia-glcore.so.334.21",
            "/usr/lib64/libnvidia-tls.so.334.21",
            "/usr/lib32/libnvidia-glsi.so.334.21",
            "/usr/lib32/opengl/nvidia/lib/libGL.so.334.21",
            "/usr/lib64/libnvidia-glsi.so.334.21",
            "/usr/lib32/opengl/nvidia/lib/libEGL.so.334.21",
            "/usr/lib64/opengl/nvidia/lib/libGL.so.334.21",
            "/usr/lib32/libnvidia-tls.so.334.21",
            "/usr/lib64/opengl/nvidia/lib/libEGL.so.334.21",
            "/usr/lib32/libnvidia-glcore.so.334.21",
            "/usr/lib64/opengl/nvidia/lib/libGL.so.1",
            "/usr/lib64/opengl/nvidia/lib/libEGL.so.1",
            "/usr/lib32/opengl/nvidia/lib/libGL.so.1",
            "/usr/lib32/opengl/nvidia/lib/libEGL.so.1"
        ]
    ]
}

So I guess this means that all the orphans come from nvidia-drivers.
So I am initially not unmerging/remerging emul-linux-x86.
That is my plan will be

  move orphaned files listed above to a holding area
  let revdep-rebuild do its thing
  wait 30 days
  delete the holding bin

Thanks for explaining.
allan

Reply via email to