Auto-connection for gnome-3-24 content interface

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.

Ok, thanks.

+1 for allowing any app to auto-connect to this interface. Note, we need at least one other reviewer to vote before granting the snap declaration.

1 Like

I just noticed I’m affected by this the other day. handbrake-jz stopped working and prompted me to do

snap install --edge gnome-3-24
snap connect handbrake-jz:gnome-3-24-platform gnome-3-24:gnome-3-24-platform

I’m told the --edge may not be necessary, but that’s what the error message in the terminal asks me to do.

At this point, more than one week has passed, so tallying votes:

1 vote for
0 votes against
0 votes abstained.

There are not enough votes at this time to grant the auto-connection. Adding the 3 day extension to the voting period (to be tallied on Aug 9 or after).

Directly pinging a few store reviewers to push this along: @niemeyer, @Wimpress, @tyhicks and/or @natalia can you vote on whether to allow or deny this auto-connection?

As a bystander, I’d like to put my voice behind this anyway, so that corebird snap can be reduced in size - from 80MB to 40MB (ish) by leaning on the platform snap, so autoconnection would be awesome.

I didn’t say you shouldn’t use that one for applications.

What I said was actually this:

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

Consider glibc for example: https://abi-laboratory.pro/tracker/timeline/glibc/

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
moving/changing ABI?

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
enough?

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.

How do we organize that?

But what “bits”?

The picture looks like

[base snap] <- [platform] <- [application snap]

instead of

[base snap] <- [application snap]

If the base and platform snaps don’t change what can be the issue?

I’ve provided details for that exact question already, including a link to the exact bits changing in something as fundamental as glibc.

The picture also doesn’t look like that. The picture is that you have data from all three snaps in the same filesystem at once, and they can all change independently.

I’m a bit stuck in terms of how to explain properly that this is an issue unless we’re planning for it not to be an issue.

Snaps update automatically and silently. If the GNOME platform snap is updated to GNOME 3.26 then that could break all the apps that depend on it and that reintroduces the dependency hell issue on traditional package managers that snappy is avoiding. You seem to be proposing that there’s different snaps for different GNOME versions so that avoids the issue because snaps can depend on GNOME 3.24 and then update to depend on GNOME 3.26 when they’re ready but snappy doesn’t really currently have separate snaps for different versions of software (it has tracks and channels instead) - so this is also a rather big step (though this seems the most sensible solution). Niemeyer is right though, what you’re proposing could be a massive issue, needs careful thought to make sure it isn’t.

The other thing is that having a platform snap introduces a weak point for the applications that depend on it because if a base snap update breaks the platform snap (or if the platform snap doesn’t work for certain base snaps) then all the applications that depend on said platform snap are broken and can’t do anything about the issue themselves other than re-factor so that they no longer depend on the platform snap and they thus are restored to their previous file size. Or the platform snap is updated to fix the issue, but for the time that it’s broken, all the applications are broken too.

Your first point is valid in general but already handled by the proposal here since the snap is named as gnome-3-24.

For the second point, I’d consider the base snap breaking the platform snap over an update as a bug in the base snap itself. When someone puts forward a base snap, there’s an implicit contract between the provider and the consumer of that snap that the interfaces (in the more general sense of the term) will remain compatible.

The problem that I’m trying to put forward is that there’s a hidden elephant in the room when we name a snap as gnome-3-24 and make it globally available for interface connections, which is that the world will continue moving forward and will inevitably be made incompatible at some point. We need to address that in a way that makes it clear when it does happen, and make it easy to tell what is compatible with what.

I’ve provided details for that exact question already, including a
link to the exact bits changing in something as fundamental as glibc.

Well, the example you provided is glibc and that library is part of the
core snap not the platform, but you are right it’s a good example. If
the glibc ABI change then we have an issue so we should better make sure
that’s not the case.

That ABI stability problem is common to the core and platform snaps, I
guess you have tools or processes in place to check that the core is not
changing in incompatible way? Maybe those could be used in a similar way
on the platform snap?

I’m a bit stuck in terms of how to explain properly that this is an
issue unless we’re planning for it not to be an issue.

Right, we are planning for it to not be an issue. The platform snap is
tracking a stable serie from a trusted upstream, the people maintaining
it have experience dealing with library updates&toolchains and are going
to make sure there are no problematic changes included in the updates
and we plan to test the updates on existing snaps before pushing them out.

Is there anything else we can do that would increase your confidence in
that platform snap?

I don’t want to derail the conversation but in working through the wayland interface, I discovered that the gnome-sudoku snap, connected to the gnome-3-24 platform snap, running on 16.04 ubuntu-gnome-desktop wayland session and forcing the use of wayland resulted in:

(gnome-sudoku:3064): Gdk-WARNING **: Wayland compositor does not support xdg_shell interface, not using Wayland display

I talked to @kenvandine about this and he stated that this is not a supported configuration and they’ll make sure to use x11 (ie, Xwayland) instead of wayland for snaps that use the gnome-3-24 platform snap (fine).

While the desktop team is going to address this particular issue, it underscores that content snaps may not work everywhere. Snaps all currently target ‘series 16’, but might be built from newer or older environments, but may be installed on arbitrary classic distro releases that might be newer or older than series 16 or the build environment. Given all this, it seems plausible that libs in the gnome-3-24 snap might be incompatible with libs/services/etc on other distros.