Dependency issues when sharing a library through content interface

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

"don’t do things that break." is simple to suggest, but harder to police when multiple projects are involved (even from a single publisher).

To take the example that has broken a few times recently:

mir-libs provides a mir-libs interface.

Now, in the .deb world we can make an "ABI compatible" release which includes new functions. In the snap world the recommendation is that we need to create a new snap for every ABI change. Vis:

mir-libs-0.26.0 provides a mir-libs interface.
mir-libs-0.26.1 provides a mir-libs interface.
...

Now a client or server built against 0.26.0 will work with 0.26.1 (but the reverse is potentially not true) but there's no nice way to connect them up.

And a /client/ built against 0.21.0 will work with either of the above. Again, there's no nice way to connect them up.

A further constraint (imposed by Mir) is that the server & client need to be connecting to the same version and for the client to connect to a second ("mir") interface shared by the server.

As things stand it is possible to make things work, but it is very fragile. Ensuring that clients and servers are built and connected to "the right thing" has no tool support.

Two things that would help:

/1/ being able to define connect logic to find a compatible interface provider.
/2/ being able to re-export an imported interface as part of another (so the client need only connect to the server "mir" interface, which contains the mir-libs interface the server is using).

> 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.

Last I heard that wasn't actually the case: https://lists.ubuntu.com/archives/snapcraft/2016-December/002190.html . Has that bug been fixed, then?

Thank you for the suggestions:

/1/ being able to define connect logic to find a compatible interface provider.

/2/ being able to re-export an imported interface as part of another (so the client need only connect to the server "mir" interface, which contains the mir-libs interface the server is using).

I'd like to split this bug into two bugs and respond accordingly.

As for /1/ I think the essence must remain that the content interface's content attribute MUST encode compatiblity. If there are internal complexities they must be hidden behind the library. For example if there are several variants there must be a compatible shim that can find and load the right variant for the given connection. Note that this does not influence the set of files provided, just how they are used. I don't think snapd should be in the business of doing control at that depth simply because it is very application and problem specific.

As for /2/ this is understood and, for a brief moment, thought to be done but it doesn't actually work as I now understand. There is a separate bug tracking this (I'll try to find it shortly) so I'd like to leave this part out. For the purpose of adding some useful information it can also be handled in one of two ways: explicitly, so that snapd models transitive sharing and implicitly, simply because of the mechanics involved.

If we agree that this bug is about /1/ and /2/ is tracked separately I'd like to close this as WONTFIX. Again, please don't regard this decision as final, we're open to discussion and we can discuss either here or on another forum. I just don't think that anything can be done about this bug in the scope of the current design of snapd.