libGL and snaps

Is there anything preventing you from adding a content interface slot to your kernel snap to keep the kernel space/user space parts in sync?

Can content-interfaces be auto-connected?

Is there a concept of “standard” content-interface names? To avoid different snaps implementing the same thing under different names “gl-libs” “gllibs” “opengl-libs” etc…

I know that the user can connect them anyway, but standardized naming would make auto-connecting easier, no?

1 Like

i’m not sure the kernel snap fully allows (content) interfaces atm, will have to try that …

Yes, the base declaration allows auto-connecting content interfaces when the slot and plug sides are from the same publisher. Snap declarations can be used to expand that-- indeed, this is exactly what is happening with the gnome content snap.

I just had a quick conversation with @zyga-snapd who told me that overlaps between content interface and layouts are not possible.

This makes the plan to use a content interface for the GL libs extremely limiting … i.e. if you have some binary thats linked against a certain hardcoded library path (for example every raspbian based binary using GLES will have /opt/vc/lib hardcoded) it will not be possible to use a layout to re-map the libs you got from the content interface of a hardware snap or a kernel snap.