The right way is to uninstall nVidia drivers before update and reinstall them after. nVidia installer saves original libraries and restores them during uninstall. If you “just replace symlink” saved libraries are not updated. If you decide to uninstall nVidia later it may happen that saved versions are no more fully compatible with new Xorg, leading to hard to diagnose problems.
RPM avoids this issue by making it possible to not install original GLX libraries in the first place.
But I know what you are talking about, as I regularly recreate the symlink under Fedora and Ubuntu, also have functions in scripts to do that. If when you install the driver manually, it puts the module in /usr/lib64/xorg/modules/extensions/, try to move it to /usr/lib64/xorg/modules/updates/extensions/ and create the symlink there.
As I see it the problem is with libGL.so The packaged driver installs this module and it’s pointers under /usr/X11R6/lib or lib64, the “hard way” installs it under /usr/lib or lib64, thus overwriting the original xorg libGL.so and it’s pointers. And consequently and update of xorg-x11-server will overwrite the Nvidia libGL.so in the latter case.
@PTA, is it possible the RPM is placing the modules in a different path than the one used for the manual/hard way? I don’t have openSUSE with me right now to check if that **updates **folder exists, or its contents.
Either way, on my laptop I uninstalled and re-installed the driver the hardway, then on my desktop just did a simple update on the symlink and both are performing as expected so far.
I got my desktop effect transparencies back, 3D effects and 3D capability in various programs so it’s all normal now.
The symlink trick was what the results from searching kept telling me, so I gave it a go, and it worked.