I chose Tumbleweed because I really like the rolling-release model, and I would like to stay with it. However, my recent experience with NVIDIA has made me wonder whether Tumbleweed should depend so heavily on NVIDIA’s own openSUSE repository.
The problem
After the 610 branch became available, Tumbleweed’s repo-oss already contained the 610 NVIDIA kernel module packages (nvidia-open-driver-G07-signed-cuda-kmp-default), while the NVIDIA repository was still providing 595.84 userspace packages.
The 610 userspace was available through the CUDA repository, but the 610 32-bit userspace packages I needed were not available at the time, leaving 32-bit support on the older branch. As a result, zypper could see NVIDIA components from three different sources with incompatible versions.
This does not appear to be an isolated incident. Similar NVIDIA version synchronization problems have been discussed in the openSUSE forums:
https://forums.opensuse.org/t/suggestion-nvidia-getting-out-of-sync/192588
https://forums.opensuse.org/t/nvidia-metapackage-does-not-force-driver-component-version-sync/195471
For a rolling release, I find this particularly problematic. Tumbleweed moves quickly, but part of the NVIDIA stack is still dependent on the update cadence of an external repository.
Other distributions show that there are alternatives
The 610 32-bit userspace packages I was unable to get on Tumbleweed do exist in other Linux ecosystems.
RPM Fusion independently packages NVIDIA’s proprietary driver for Fedora, while Debian has its own NVIDIA packaging ecosystem. These approaches can provide the kernel module, userspace libraries, and 32-bit components as a coherent stack without relying on NVIDIA’s distribution-specific repository.
This makes me wonder whether openSUSE could take more ownership of the NVIDIA packaging layer, for example by maintaining the relevant packages and synchronization through OBS.
I am not suggesting that openSUSE should develop the NVIDIA driver itself. I understand that NVIDIA’s proprietary userspace comes with licensing and redistribution constraints, and that maintaining these packages, kernel modules, 32-bit libraries, and QA would require significant maintainer resources.
My question is whether a more independent packaging model has been considered before, perhaps similar in spirit to RPM Fusion. If it has been considered and rejected, I would be very interested in understanding the technical or practical reasons.
If there is already a community or OBS effort working in this direction, I would also be happy to help with testing. I am currently using NVIDIA’s .run installer with DKMS, so I can provide comparison feedback and would be happy to test community-built packages.
I ended up using the .run installer because it was the most predictable way to get a consistent driver stack, and it works. However, I would much rather have zypper manage the entire NVIDIA stack for me.
Ultimately, I don’t think the solution should be for NVIDIA to give openSUSE special treatment. I would rather see a packaging model where Tumbleweed can maintain a consistent NVIDIA stack without being so dependent on the update cadence of an external repository.
English is not my first language, so I used AI to help write and polish this post. The experiences and opinions described here are my own.
Welcome to the openSUSE Forums!
Due to licensing issues, distribution of proprietary Nvidia software must come from an Nvidia controlled server.
You should find related discussion on the Forums.
That said, a few -meta packages are available on the repo and should be installed to automatically solve version mismatches between packages, but those are not available for the cuda versions.
Nvidia has the wrong license, only a small part is put to opensource with another license.
The Nvidia package are build on the OBS, send to Nvidia and published by Nvidia.
But the opensource part of the drivers are build and published faster as the Nvidia part.
As the decision was made, to enable a Tumbleweed Repo with prebuild Nvidia Packages, the question for me was:
is this a good decision?
Yes the decison was not bad, but you see, what can happen.
It is as it is.
PS
I use on Leap 16.0 the open-G07-kmp from the build Repo.
This one is offered 10 days ago. But I can not install it also because of the missing Nvidia parts in the Nvidia Repo.
So you can see, what time is between building— Factory---- Tumbleweed
And Nvidia…
32bit support was dropped for cuda some time ago? So it will never appear in the cuda repository kmp.
Thanks, this explains the architecture much better. I wasn’t aware that the NVIDIA packages are already built on OBS and then sent to NVIDIA for publication.
In that case, I think the real issue I ran into is less about openSUSE not packaging NVIDIA, and more about the synchronization gap between the open driver, NVIDIA’s proprietary userspace, and the CUDA variants.
The point about the CUDA packages is especially relevant to my case, since the 610 CUDA repository did not provide the 32-bit userspace packages I needed, while the regular NVIDIA stack had its own version synchronization mechanism.
I understand now why openSUSE cannot simply take over redistribution of the proprietary userspace. It would be interesting to see whether the synchronization/meta-package approach could be extended to the CUDA variants, though.
Thanks, that explains it. I wasn’t aware that 32-bit support had been dropped from the CUDA repository.
That was actually the main reason I couldn’t use the CUDA repository for my 610 setup. I need the 32-bit NVIDIA userspace for Steam/Proton, so a 64-bit-only 610 stack isn’t sufficient for my use case.
This also explains why the CUDA repository wasn’t really an alternative to the regular NVIDIA repository for me.
It does make me wonder whether there is any supported way for Tumbleweed users to get a current NVIDIA stack with 32-bit support, without relying on the older NVIDIA repository cadence.
So, if I understand correctly, for a Tumbleweed user who needs both a current NVIDIA driver and 32-bit NVIDIA userspace, the supported choices are essentially either using the older NVIDIA repository, or using the .run installer. Is there currently any recommended third option?
There are actually two other options, flatpak steam installed as your user and distrobox with a distribution of your choice and steam installed there…
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.