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?
We also want this to auto-connect for 3rd party app developers publishing apps that need GNOME.
1 Like
It’s clear you want people to connect to this snap, but can someone comment on this?
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.