Wanted to ask what approach can you think of in a situation we in the Mir team are in. It’s somewhat similar to the libGL¹² problem as it deals with hardware enablement.
Background
Mir is a library for building display servers. The current distribution model is that there’s a PPA that consumers of Mir are supposed to use when building their software (snaps or otherwise). These libraries then need to made available on the target deployment, either via enabling said PPA, or bundling them in the case of snaps.
Direction
We’re thinking of improving this situation (PPAs are not first-class citizen in Snapcraft) and one approach we thought of was the framework snap approach.
Problem
The issue is that apart from Mir itself, the deployment needs target-specific userspace bits. Today those are mir-graphics-platform-{mesa-x,mesa-kms,eglstream-kms} supported by the Mir team, but there’s also an external -android platform and a -mesa-wayland one in the works. It’s expected that there will be custom platforms for different hardware.
Consumers are protected from ABI changes be means of MirAL so in an ideal world they would work regardless of updates of Mir itself or the platform backends. But we can’t include all of the platforms in the proposed miral-2-core18 framework snap, nor apparently can we share another snaps’ contents up to the consumer.
We would like to avoid for consumers having to connect directly to a versioned mir-graphics-16-core18 interface as that would mean they’d become unnecessarily incompatible with a platform that, say, only supported a newer platform ABI.
Ask
What do you guys think? Is there any way with snaps today that something like this could work? How would the proposed changes for GL libs affect this? Would snapd have to learn of Mir platform bits to allow this to work?
Am I right in assuming that miral-2-core18 (referred to as the framework snap) is a snap providing a slot using the content interface and you do not want to overload that with support for all the existing rendering (triple quote that) platforms?
I have a feeling that Problem is stating more that one problem
If so, maybe exploring the idea of having multiple framework snaps, one for each platform sounds feasible… there’s a default provider for the slot of an interface, but any snap implementing the interface can be plugged in.
This should at the least solve the PPA problem, correct? To the least, similar to installing the correct deb from a PPA.
AFAIK, the name the snap, or thus provider, needs to be versioned when you cannot guarantee compatibility.
It might be interesting to have some way to describe the hardware for the default provider to be the appropriate one for that hardware. If all I said makes sense, we can involve the snapd team.
I’ve been discussing this with @Saviqelsewhere and the OP attempted to summarize where we’d got stuck in our deliberations. Let me try add a bit of exposition.
Yes. With the way that the MirAL API evolves I’d expect that miral-2-core18 would provide slots miral-2.4-core18, miral-2.5-core18 etc.
It is not only that we don’t want to overload that with support for multiple graphics stacks, it is that these we don’t “own” all of the possible stacks: they can be supplied by other organizations.
Again, yes. That’s what we were thinking.
So we’d have a mir-graphics-16-core18 and later a mir-graphics-17-core18 interface.
Now it is the miral-2-core18 snap that has a dependency on a particular one these, not the application snap using the framework.
But, as we understand it, for the contents (.so libraries) to be available to the application, these need to be pulled into the application snap.
That means that a change from mir-graphics-16-core18 to mir-graphics-17-core18 could not be transparent to the application snap as it would need to be updated at the same time as the framework snap.
