Upgrading from x11-drivers/nvidia-drivers-195.36.31 to x11-drivers/nvidia-drivers-256.52 with FEATURES=collision-protect on my ~amd64 system, I got this error message: * Detected file collision(s): * * /usr/lib64/libvdpau_nvidia.so * /usr/lib32/libvdpau_nvidia.so * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). As the files seem to be definitely nvidia-related, and no other package claimed them, I felt confident to emerge this without collision protection: FEATURES=-collision-protect emerge -1 nvidia-drivers So the thing is fixed for me, but perhaps you want to look into this nevertheless, and prehaps delete the files in preinst if that's what should happen.
Please post your `emerge --info'. @xmw: This bug report isn't complete.
Created attachment 245636 [details] emerge --info
I can confirm problem. I also have libvdpau installed and it looks like before nvidia-drivers wasn't overwriting libvdpau_nvidia.so coming from x11-libs/libvdpau but it was installing his own libvdpau_nvidia.so wich was named following the nvidia-driver version: previously nvidia-driver-XXX installed his own libvdpau_nvidia.so.XXX and here the xxx has been omitted curious thing: neither equery b nor portageq find the owner of the file libvdpau_nvidia.so something else is wrong petitnuage jms # locate libvdpau_nvidia.so /usr/lib32/libvdpau_nvidia.so.1 /usr/lib32/libvdpau_nvidia.so.195.36.31 /usr/lib32/libvdpau_nvidia.so /usr/lib64/libvdpau_nvidia.so.1 /usr/lib64/libvdpau_nvidia.so.195.36.31 /usr/lib64/libvdpau_nvidia.so petitnuage jms # equery b /usr/lib64/libvdpau_nvidia.so [ Searching for file(s) /usr/lib64/libvdpau_nvidia.so in *... ] petitnuage jms # portageq owners / usr/lib64/libvdpau_nvidia.so None of the installed packages claim the file(s). but I know this file is installed by libvdpau!!
Created attachment 245718 [details] /jms-emerge--info
Created attachment 245785 [details] emerge --info Same here on ~x86. # ls -lah /usr/lib/libvdpau* -rw-r--r-- 1 root root 1.1K Jun 20 21:09 /usr/lib/libvdpau.la lrwxrwxrwx 1 root root 25 Jan 11 2010 /usr/lib/libvdpau_nvidia.so -> libvdpau_nvidia.so.190.53 lrwxrwxrwx 1 root root 28 Aug 24 19:00 /usr/lib/libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.195.36.31 -rwxr-xr-x 1 root root 1.6M Aug 24 19:00 /usr/lib/libvdpau_nvidia.so.195.36.31 lrwxrwxrwx 1 root root 17 Jun 20 21:09 /usr/lib/libvdpau.so -> libvdpau.so.1.0.0 lrwxrwxrwx 1 root root 17 Jun 20 21:09 /usr/lib/libvdpau.so.1 -> libvdpau.so.1.0.0 -rwxr-xr-x 1 root root 9.4K Jun 20 21:09 /usr/lib/libvdpau.so.1.0.0 -rw-r--r-- 1 root root 975 Jun 20 21:09 /usr/lib/libvdpau_trace.la lrwxrwxrwx 1 root root 23 Jun 20 21:09 /usr/lib/libvdpau_trace.so -> libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 Jun 20 21:09 /usr/lib/libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 -rwxr-xr-x 1 root root 54K Jun 20 21:09 /usr/lib/libvdpau_trace.so.1.0.0 "/usr/lib/libvdpau_nvidia.so" points to the NOT EXISTING file "libvdpau_nvidia.so.190.53" So I believe removing corrupt symlinks is okay. After removing the symlink to the non existing file, the package could be merged fine.
x11-libs/libvdpau doesn't install libvdpau_nvidia.so, x11-libs/libvdpau is an abstraction for the specific driver implementation. It uses DRI2 to determine which implementation it should load in. This is a Portage bug as far as I can tell since previous x11-drivers/nvidia-drivers installed /usr/lib{32,64}/libvdpau_nvidia.so as a symlink to /usr/lib{32,64}/libvdpau_nvidia.so.${PV}. Instead now we install the libvdpau_nvidia.so directly as NVIDIA prefers.
I think this is and example of why we don't have FEATURES=collision-protect enabled by default. We have FEATURES=protect-owned enabled by default instead, and it will just produce a warning in this case (when "None of the installed packages claim the file(s)" as shown in comment #0).
confirming Comment #5 From Markus Rathgeb * /usr/lib64/libvdpau_nvidia.so * /usr/lib32/libvdpau_nvidia.so are corrupt symlinks pointing to nowhere and can be removed safely. then one can carry on the installation happily. Confirming comment Comment #6 From Doug Goldstein yes I didn't check properly. indeed libvdpau_nvidia.so has been previously installed by nvidia-drivers. About Comment #7 From Zac Medico yes I think this is a good example of why having protect-owned enabled by default instead of collision-protect. Thanks for pointing this out. question :why theses files have not been removed upon newer installation of nvidia-driver>195.36.31? Is it likely to happen to others packages? is there any tool to cache up all these broken symlinked .so and remove them at once?
(In reply to comment #8) > question :why theses files have not been removed upon newer installation of > nvidia-driver>195.36.31? > Is it likely to happen to others packages? > is there any tool to cache up all these broken symlinked .so and remove them at > once? Aside from implementing bug #233278, there's no opportunity to remove orphaned files. Whenever possible, it's best to avoid creating orphans in the first place.
Zac, I'm honestly unsure how these got orphaned in the first place. The symlinks were made with dosym in the ebuild.
Any word on this from the Portage dev team?
Unless the source of the orphans can't be determined, there's nothing that can be done. So, it's either a NEEDINFO or a CANTFIX.
As per the Portage team.
