Unfortunately that solution is nearly impossible to deliver.
-
MESA and friends (FOSS drivers) are implemented by a number of shared libraries. If you are running on top of Ubuntu 20.04 and use a snap that was published against “core16” (aka “core”) then libc from 2016 will be used as the source of symbols for a shared library compiled against libc from 2020. So we cannot do that. MESA also has a closer relationship to the kernel as many things are implemented in tandem.
-
Nvidia uses a binary user space driver that is carefully linked and works pretty much on any libc ever shipped with snaps, as long as the kernel portion is present. This means that as soon as you provide the set of magic .so files from Nvidia (that they build once for everyone) things should be good.
Where does this leave us:
If all of the userspace bits, excluding services (we assume those are provided by classic world) are packaged in a “hardware support” snap, with appropriate meta-data about what it technically depends on (like kernel features or base snap name) then application snaps could be connected to such a hardware support snap in a compatible way. Note that this gives us flexibility:
- on a single system you could have an app snap using a stable release of a hardware support snap for one GPU.
- on the same system another app snap could be using a different release (e.g. edge) for some bleeding edge bug fixes that affect a particular application.
- on the same system yet another app snap built against a different base snap (different ABIs) could use the same conceptual release (stable) of a driver snap, just built for the correct ABIs (more recent libc)
- on the same system there might be second GPU from a different vendor and snapd might understand enough to switch between “power efficiency” and “performance” modes by re-connecting a set of snaps to a different slot providing the hardware accelerated rendering.
- on the same system the classic world would continue to use classic packages (snaps don’t break classic world)
- as a special remark, in all the cases the classic world would provide the kernel part of the driver as well as (any) system services.
All of that is very hand-wave-y because it will be a while until this is implemented but the model is sound and scalable to more GPU vendors, more releases, more ABIs, etc. It also cuts snapd from the potential source of instability related to trying to locate the userspace part of the driver on the classic filesystem (which differs widely across distributions).
I think we can have a much better result by developing towards “hardware support” snaps, getting MESA and Nvidia on board (bootstrapping and handing off to them eventually). This will work for all distributions, for all classes of hardware.