[elrepo] nvidia-x11-drv and GLVND

[Phil Perry]

On 23/08/16 14:57, Manuel Wolfshant wrote:
> On 08/23/2016 04:28 PM, Harry Mallon wrote:
>>
>> Alternatively, we could try doing something clever, and ship both
>> versions of the libGL.so lib in the same package, with one enabled by
>> default (maybe through a symlink), and write a switcher app to allow
>> users to switch back and forth for testing etc by switching to the
>> appropriate libGL.so lib and rebooting. I'm thinking of something like
>> the util Red Hat uses to switch between Postfix or Sendmail MTAs - it
>> could be a simple command line script.
>
> No additional script is needed. All available MTAs make use of the
> alternative system which can be used for nvidia as well.
>


Ah, thanks Wolfy - I've used it in the past as a user to switch MTAs but 
have never looked at it in detail at a technical level to see how it 
works or how it might otherwise be exploited.

So, for those not familiar, NVIDIA now ships a new "GL Vendor Neutral 
Dispatch (GLVND) [1] infrastructure for Unix OpenGL drivers allows 
multiple OpenGL implementations to coexist on the same system". See here:

https://devtalk.nvidia.com/default/topic/915640/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/

At the packaging level, the only differences are that there are 2 
versions of the libGL.so lib - one that is GLVND enabled, and another 
legacy (non-GLVND) version. We currently ship the legacy version. 
Additionally, there is one other GLVND lib (libGLX.so) that we don't 
currently ship as it would cause conflicts.

So our choice are (see my previous comments Harry copied to the list):

1. Just ship the new GLVND enabled drivers at the next major release and 
hope they don't break anything. If they do, feel free to file bugs 
upstream with nvidia / affected 3rd party software providers. The new 
drivers may be fine and this may be the simplest solution now they've 
had time to mature since the original beta release.

2. Ship two package sets, one GLVND enabled and one legacy and let the 
user choose which version to install. This isn't a long term solution 
but could be a way forward in the short term

3. Ship all the libs in one package and come up with a way to 
install/copy the required libs in place, run ldconfig and reboot (or 
restart Xorg) allowing users to switch between GLVND enabled and legacy 
drivers with little more than a reboot. We could use a script to remove 
the old libs and copy the new libs in place from a tmp directory, run 
ldconfig and trigger a system restart. This solution isn't exactly out 
of the KISS packaging handbook, but isn't that far removed from what the 
nvidia installer does - has an option at install-time to select GLVND 
(default) or legacy drivers.


So at this point I'd like to have a discussion around our options (maybe 
there are more that I haven't thought of). Option 1 is obviously the 
simplest but is difficult to evaluate without knowing the stability of 
the current drivers so I would propose that I start by releasing a GLVND 
enabled package set to the testing repo and lets see how we get on with 
those. If they cause issues with OpenGL applications then we can 
consider options 2 and/or 3 for providing legacy drivers.

Note: In the context of this discussion, legacy refers to non-GLVND 
enabled drivers, not older driver [ackages that support older hardware. 
GLVND has only been available upstream since 361.xx

Thanks