I’m told the snapd team plans some near-term work to enable sharing a userspace lib so that mir-kiosk and mir client snaps (like chromium) will not both need to both include the lib (on Core), thus simplifying such projects.
Specifically, a potential near-term project will use the Mali 400 GPU (on the Allwinner A64 SoC, on a Pine64 SBC), so the corresponding Mali userspace GL lib needs to be available (via mesa) for both mir and the client snap.
What is the status of this work? Is the plan to use content interface for this?
The work is planned for this cycle (between Ubuntu 18.04 and 19.04) but has not started yet. It may slip to the next cycle. We did plan to use the subsystem behind the content interface (mount namespace manipulation) but it would be only one of several elements.
It seems to me it would be cool if snap packages would be created for example from MESA(Qt, GTK and other) or with something similar. And libraries would be forwarded to the system.
And then you would indicate in your snap package which version of this set of libraries you require. And everyone should do that. Then there will be no copies.
But I don’t know if the snap developers themselves will do that. But that would be the most convenient solution.
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.
I think if the snap package implements a mechanism through which it will be possible to say which version of the library is minimal or maximally usable, then it seems to me that this way you can solve the problem.
If you are talking about the host providing userspace libraries I explained above how that is impossible to use in the general case but perhaps I’m missing something. What is the motivation for using host libraries? Snaps change the game by making dependency complexities, largely, a thing of the past. Is there a specific workflow where using the host library is important to you?
