Auto-connection for gnome-3-24 content interface


#1

The Ubuntu Desktop team has created the gnome-3-24[1] 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.

default-provider: gnome-3-24:gnome-3-24-platform

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.

Thanks for your consideration

  1. https://dashboard.snapcraft.io/dev/snaps/7777/

Use the system gtk theme
Call for testing: MusicBrainz Picard
Gnome-calculator problem
Should mir-libs still auto-connect?
Cannot build Gradio snap
Should ubuntu-app-platform still auto-connect?
Assorted questions about snapd use
#2

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?


#3

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?


#4

We also want this to auto-connect for 3rd party app developers publishing apps that need GNOME.


#5

It’s clear you want people to connect to this snap, but can someone comment on this?


#6

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.


#7

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.


#8

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.


Content interface connection issues
#9

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?


#10

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.


#11

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


#12

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?


#13

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.


#14

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?


#15

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/


#16

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?


#17

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?


#18

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?


#19

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?


#20

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?