[elrepo] Announcement: EL5, EL6 and EL7 Updated NVIDIA drivers [367.27]

[Phil Perry]

On 21/06/16 04:43, Manuel Wolfshant wrote:
> On 06/20/2016 05:11 PM, Phil Perry wrote:
>> On 20/06/16 14:39, Phil Perry wrote:
>>> Announcing the release of updated NVIDIA 367.27 packages into the EL5,
>>> EL6 and EL7 testing repositories:
>>>
>>
>> As noted above, these packages have been release to the testing
>> repository.
>>
>> This release (well, actually NVIDIA's short term 364.19 release) is
>> the first release to include NVIDIA's Wayland support:
>>
>> http://www.nvidia.com/Download/driverResults.aspx/101818/en-us
>>
>> However, the new libnvidia-egl-wayland.so lib has a dependency on
>> libwayland-client.so and libwayland-server.so which are not a part of
>> RHEL:
>>
>> $ objdump libnvidia-egl-wayland.so.367.27 -p | grep -i NEEDED
>>   NEEDED      libpthread.so.0
>>   NEEDED      libc.so.6
>>   NEEDED      libdl.so.2
>>   NEEDED      libwayland-client.so.0
>>   NEEDED      libwayland-server.so.0
>>   NEEDED      libEGL.so.1
>>
>>
>> Consequently, if we include this new lib in our nvidia packages, yum
>> complains about the missing deps and it is not possible to install the
>> packages on RHEL.
>>
>> Wayland is intended to be the replacement for X, and was due to become
>> the default in Fedora 24 but I believe it wasn't ready in time so this
>> has now been pushed back to Fedora 25. From what I've read there also
>> appears to be some disagreement over NVIDIA's implementation of
>> Wayland support.
>>
>> So the question is how do we handle this new Wayland lib in our nvidia
>> packages on RHEL? If we include the lib then we would also need to
>> package libwayland-client and libwayland-server as dependencies[1].
>> The other option is to just ignore and not package
>> libnvidia-egl-wayland.so for now, and this is what I've done in our
>> 367.27-1 release that has just been released to the testing
>> repository. I've only performed minimal testing on these packages so
>> please test and confirm they behave as expected on your systems.
>>
>> Given Wayland is relatively new technology and clearly not ready for
>> an Enterprise Linux environment yet, and is unlikely to be supported
>> on any current release of RHEL, I'm inclined to ignore it for now.
>> Presumably those wanting Wayland are using Fedora not RHEL.
> 100% agree with that
>
>
>>
>> The other option would be to split this lib out to a wayland
>> sub-package such as nvidia-x11-drv-wayland for those who want to
>> consume it but this wouldn't be my preferred option.
>>
> That's what I would normally do, following Fedora's policy of including
> everything ( including a spare kitchen sink )
>
>
>> Thoughts and feedback welcome.
>>
>>
>>
>> [1] I note these packages are available on EL7 from the nux dextop
>> repository:
>>
>> $ sudo yum list libwayland-client libwayland-server
>>
>> Available Packages
>> libwayland-client.x86_64 1.5.0-4.el7.nux nux-dextop
>> libwayland-server.x86_64 1.5.0-4.el7.nux nux-dextop
> In this case I would also either ship the same packages in elrepo or (
> my preferred option ) include a README instructing the users to install
> the libwayland packages from Nux's repo in the same time as or prior to
> installing nvidia-x11-drv-wayland

I guess repo closure is the issue here - do we want to maintain repo 
closure or are we happy to have elrepo packages rely on another 3rd 
party repo. Personally I think repo closure is important thus I think it 
important any deps are provided by elrepo, even if we are only 
rebuilding the Nux offering.

Also, Nux informs me those libwayland packages are only currently 
available for EL7, not for EL5/6 in his repository. I have no idea how 
easy / if it's even possible to build wayland packages against the older 
EL5/6 code base, but I feel it important that whatever solution we 
adopt, we are consistent across all releases where possible.