The Ubuntu Desktop team has created the gnome-3-24 snap which provides supported backports of libraries needed for GNOME 3.24 apps on 16.04 via a content interface. As we are populating the store with desktop apps which utilize this content interface, we would like a snap declaration to auto-connect this interface.
We have some snaps already in the store using this interface, and many more on the way. Examples include: gedit, gnome-dictionary, gnome-clocks, gnome-calculator, gnome-sudoku and quadrapassel.
Keep in mind that snaps from the same publisher already auto-connect, so, AIUI, the examples you listed of consumers for this interface should already auto-connect.
Can you confirm that you want this snap to auto-connect for snaps from any publisher? If so, can you also comment on the stability of the libraries, APIs, ABIs, etc of the gnome-3-24 snap and any other information stating the promise of updates to this snap not breaking 3rd party publishers?
The GNOME platform snap is published by the Canonical account but Gustavo didn’t want us to use that one for the applications so Ken has published those under his account (and other team members are going to do the same) so the publisher is different?
The gnome-3-24 platform snap is built from the ubuntu-desktop backports PPA for which we are maintaining specifically to provide a supported gnome-3.24 base for GNOME apps and app developers to utilize. It’s GNOME 3.24 which is ABI stable and we are committed to only push updates from the 3.24 stable series. We’ll ensure a variety of the GNOME apps are well tested before pushing updates of the gnome-3-24 snap to the stable channel.
So it’s just a matter of making it clear that it is maintained by a team at Canonical (and will continue to be) and having some information available so we can tell which snaps those are and what is the maintenance plan, ideally here in the forum.
With that said, part of the point of that particular content interface on gnome-3-24 as I understand it is being a base for other snaps to rely upon, so being able to auto-connect it sounds interesting nevertheless. The point above by @daniel already shows that being desired.
I’d like to thread carefully while doing that though, only because this is the first time we’ll be opening up that specific door, which means we have very little experience with that sort of interface being public so far. To that end, can you respond to @jdstrand’s question above in a bit more detail:
From the name of the snap and its interface, it doesn’t look like that was accounted for. In particular, that snap and interface are globally visible, not only across multiple distributions but also across multiple versions of those which will span several years. What happens when there are ABI breakages that take place because not Gnome itself but the underlying infrastructure changed? How should one pick the right “gnome-3-24” snap and interface?
Could you give some details on what you call “the underlying
infrastructure”, are you speaking about the core snap changing its ABI?
If that’s the case it’s going to impact any snap and not only the
platform (there is no reason the gtk library built into the platform
would be any different from the one bundled by e.g vlc). How do we (plan
to) handle those cases for non-platform snaps?
No, the point is unrelated to the core snap or snapd. Think about any change outside of the Gnome source code that could make an application binary built 5 years from now incompatible with the libraries built today.
Sorry but I don’t understand how that’s specific to the platform snap
and not going to impact any application snap that e.g bundles gtk the
same way. Could you maybe give an example (real or imaginary) to help me
to understand what you mean there?
The application that bundles gtk holds all of its libraries inside the same snap. When you cross the line between snaps, then there’s an ABI being promised which we need to understand and plan for. That’s the most important reason why we constrain content interfaces to the same publisher, and also part of the rationale for why there is more bundling in snaps than debs. Once you introduce a more traditional dependency, then all of those issues need to be accounted for again, and now it’s not about a Linux distribution anymore, but many versions of many distributions.
Sorry but I’m still unsure to understand what you mean. You wrote “when
there are ABI breakages that take place because not Gnome itself but the
underlying infrastructure changed?” but there is no infrastructure under
the gnome platform snap putside of ubuntu core, what part could be
When there is a content interface, there are three snaps involved: the base snap (core for now), the snap with the interface plug, and the snap with the interface slot. There are binaries on all of those, and they must work together. How do we organize things in a way that will continue to make sense over time?
Well, the problem definition is simple there. We only add one extra part
compared to a normal snap, the platform. The way to make sure it doesn’t
create issues for snaps using it is to ensure that there is no
incompatible changes made ever to that platform snap.
GNOME stable versions don’t change much (if at all after a while) and
it’s our job to make sure that if we do an update it doesn’t include any
abi/behaviour change (basically the same job than we do today for SRUs
or security updates).
Ken stated in that topic that updates to that platform snap are going to
be stable serie changes from GNOME and careful tested by us, is there
anything more we can do to help you making more confident that it’s good
Again, the issue is that the bits outside the platform snap are not under control. Even if the platform snap remains unchanged, the other bits will change, and possibly make the interaction with that platform snap impossible. It sounds like we need to acknowledge these issues and plan for them.
Note that on a typical snap, there are only the application snap and the base snap. The base snap will often be based on the underlying platform being used (say, Debian 10), which means the built bits will be compatible with it. The application is obviously compatible with itself, because it was just built. The gnome platform is the odd bit out in this picture, because it was compiled in a different platform and may not be compatible anymore.