Comment 1 for bug 1666690

Simple: don’t do things that break.

There’s a reason it’s we don’t allow to share suff willy-nilly between any two snaps. They must come from the same publisher or they must come from someone we trust to make sensible choices.

The examples you gave a just the tip of the iceberg. There are plenty of issues that one can have even if ABIs are compatible. The best that we can do, and what snaps are doing, is to limit the damage. The defaults we allow everyone to use are „you can share stuff any way you like amongst your snaps” are good because they limit the damage to that one, particular snap provider. If I push an update that breaks my snaps, well, I broke *my* snaps.

When this circle is broadened then the owners of the shared part need to be responsible and really extra careful with what they are doing.

The mechanism for sharing only compatible content is already in place. It is the „content” attribute of the interface. Unless it matches snapd will not attempt to make the connection. On other words, in the circle of snaps a given entity maintains the content attribute of the content interface can be used to indicate compatibility.

There’s a special case of content that the platform must share (such as the libglvnd you’ve highlighted) but this is a separate problem that I’m aware of. The current approach for that was a nice hack that got us off the ground but it is something that we must address going forward. For everything else, the content interface is sufficient.

Let me know if this answers your question or if you have ideas that are worth putting into snapd as a mechanism.

Best regards
ZK