FS#78852 - [lib32-nvidia-utils] Consider adding versioned dependency on nvidia-utils
Attached to Project:
Community Packages
Opened by Emil (xexaxo) - Wednesday, 21 June 2023, 13:27 GMT
Last edited by Toolybird (Toolybird) - Monday, 26 June 2023, 21:43 GMT
Opened by Emil (xexaxo) - Wednesday, 21 June 2023, 13:27 GMT
Last edited by Toolybird (Toolybird) - Monday, 26 June 2023, 21:43 GMT
|
Details
Description:
As many of you know, the nvidia drivers (as a whole) need to be updated in lock step. Meaning that you cannot have a version mismatch across any of the components - be that kernel module, GLX or Vulkan driver, or even the 32bit vdpau driver. In the usual case, you get indicative error log/message about the missmatch. When mixing 32bit and 64bit components - you get unhelpful application crash with random X details. In particular, I'm thinking of: - running one version of nvidia-utils (64bit Xorg server with its libglx.so) and, - slightly different version of lib32-nvidia-utils (aka 32bit app like steam) In the very rare case the version miss-match (32bit vs 64bit) will be due to bug in our repos or an out-of-date mirror. Although since the crash output is _very unhelpful_, I think the simpler option is to make the 'nvidia-utils' dependency explicitly versioned. Additional info: * package version(s) 535.54.03 Steps to reproduce: - install nvidia/nvidia-utils version 535.54.03 - install lib32-nvidia-utils version != 535.54.03 - run 32bit glxgears or steam - observe the crash - update the PKGBUILD, rebuild and install - `sed s/nvidia-utils/nvidia-utils=$pkgver/ PKGBUILD` - observe the proper dependencies being pulled in -> apps no longer crashes |
This task depends upon
Closed by Toolybird (Toolybird)
Monday, 26 June 2023, 21:43 GMT
Reason for closing: Fixed
Additional comments about closing: lib32-nvidia-utils 535.54.03-2
Monday, 26 June 2023, 21:43 GMT
Reason for closing: Fixed
Additional comments about closing: lib32-nvidia-utils 535.54.03-2
- our repos may have different versions of the 64/32 bit packages, we even have a handy differences page/report for those -https://archlinux.org/packages/differences/ - maintainers are humans and they will occasionally make a mistake
- the mirror may be partially out of sync - don't know about others, but I don't explicitly check the ranking and state on each Arch update
But even if it's an user error, we are talking about a one-line sed command that has practically zero maintenance cost.
The way I see it one can a) apply it (or variation thereof) or b) spend an order+ of magnitude more time, telling users its "their problem".