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.
There is nothing specific to the platform/content sharing there though. The issue is that GNOME 3.24 is not having compatibility code to work on old wayland versions, you would hit the exact same problem if you were including current gtk built from upstream git in your app snap without using a platform.
That said it’s a bug and we should make the wayland backend included in the snap work on xenial or not build it, thanks for pointing it out.
My point wasn’t to hold the wayland issue up as an example of why the gnome-3-24 snap shouldn’t autoconnect. It was to mention this as a data point for the wider conversation of auto-connecting content snaps globally.
The content interface is currently designed for the same publisher to use for that publisher’s snaps because snapd intentionally does not support strong, fine-grained dependencies. If the ABI breaks in the publisher’s content snap, that’s ok-- the publisher can manage transitioning her collection of snaps through channels, tracks, gating, etc.
Things become a lot more complicated if the content snap goes beyond the publisher because the publisher can’t fix or coordinate consumer snaps from other publishers. Therefore the conversation went to stability guarantees and preventing breakage. I think the discussion around that is really important even if the communication hasn’t lead to a clear conclusion yet.
Thinking through the whole conversation thus far, I think there are several points:
I’m not sure I captured everything @niemeyer was thinking about. This conversation got me wondering if content snaps on classic distro should maybe have additional attributes for where they are expected to work, or a declaration of what is supported, but this may be problematic too. Another option is using a group publisher (eg, motu, core-dev, etc) and saying any snaps from those groups can auto-connect (possible today).
Hopefully we can agree that we want to advocate for developers and users and do everything we can to not break them. We therefore must carefully consider global auto-connection of content snaps and not rush the conversation.
The base snap is of course compatible with itself, because it was built from one consistent place, and we won’t ever break that base because we continue to build that one base from a place without introducing binary incompatibilities.
The application picks its base, so it knows that it may expect these particular bits to remain compatible forever, until it picks a different base to move on in time. As a concrete example, if an application picks a base that was created out of Debian 8, there’s an implicit guarantee of binary compatibility because that glibc won’t change.
Now, what’s the strategy for the gnome platform? Different bases may be incompatible with that snap. How do we signal that?
The issue is not confidence on the snap or on you. The first issue we need to go through is get to an agreement regarding what the problem is. Over the exchanges above it sounds like I’ve been saying that there’s a very realistic compatibility issue that we need to plan for, and you’ve been saying you don’t see the issue. Without us both acknowledging that there is or there isn’t an issue, we can’t move on to either ignore it or solve it.
@niemeyer using
I think I can answer the question, and I might be wrong so @seb128 should confirm. But the gnome-3-24 snap which would have a slot for gnome-3-24 will always be built on top of the same base, in this case base 16 and I think this is where the tricky part of the question comes in and it is: What happens when you want to move this snap to use base 18? And I think that the answer here is that you wouldn’t (probably unrealistic) or that the naming for the snap and interface needs to somewhat imply the base it targets.
This may be confusing to the respondents as base hasn’t really been presented in a concrete way yet to a more broad audience which is probably causing confusions in the conversation and from their point of view glibc in base 16 should not change.
PS: take note that I just made up 16 and 18 as short hand names for ubuntu-16.04 and ubuntu-18.04 neither of which have agreed upon names that I am aware of.
@sergiusens The platform snap will necessarily be built on a particular environment, no matter what that environment, and it will be compatible with every base snap that matches the main particularities of that environment.
We can choose to ignore that problem for now, and then everybody would have to tell whether gnome-3-34 is
compatible with the base they’re trying to use or not, by trial and error. That doesn’t sound so great.
The introduction of base snaps is a red-herring here. Replace base by core and every described issue still exists.
@seb128 I apologize. There’s in fact no real need for us to discuss the problem at length here when your context is really Ubuntu. I’ll come up with a more clear proposal that will address your needs and also those of other distributions.
Please let me spend a moment on this and I’ll come up with a complete proposal.
Right, that issue is real but it’s not specific to the platform. Once we
get different base snaps I think we are going to need a way to specify
on what base your snap can be used.
Taking back the glibc example, libreoffice built on 17.04 wouldn’t start
on 16.04 because of c++ abi changes, which means a libreoffice snaps
built on fedora 26 isn’t going to be usable on ubuntu 16.
The issue is going to be true for the platform snap as well, but it’s
not any different from applications snaps…
Thanks, I’m looking forward reading the proposal and let me know if I
can help in any way
Yes, precisely, except that the platform does introduce an extra variable because the availability of the libraries is being made via external actions, while the base snap is cooked into the application snap, and cannot change so easily. So the snap publisher knows that a base that looks a lot like the one selected will be in place with the snap, but for a gnome-3-24-platform interface, how would one tell what the right one is? And how would the publisher even tell that the gnome-3-24 snap is the right one for that base in the first place?
We may end up going forward like this, and relying just on documentation to organize things, but I’m hoping we can do better.
What if hypothetically you could do something like base: gnome-3-24 in the app snap assuming that the here specified snap has in turn something like base: ubuntu-16.04? Said snap could reliably be built on the right image.
Here is a simple proposal and an attempt to make the idea a bit more clear:
https://youtu.be/KEm5WNsAnbE?width=690&height=388
Hope this format proves useful to shorten the keyboard distance. I may end up doing a bit more of those if so.
I like the proposal overall because it is encoding somewhere in the name and/or the slot name the distribution release (eg, ‘16-10’ for Ubuntu 16.10) which makes it easy to both reuse the content (“as a developer, I want to build a snap using Ubuntu 16.10 toolchain and binaries and I want to use the GNOME content snap. Oh, I’ll pick gnome-16-10”) and helps avoid user confusion because the correct content snap can easily be pulled in for a given snap.
I also like how the proposal acknowledges that this is a short term way to move forward since it is more about giving developer guidelines for collaboration rather than an implementation that enforces things, but that we’ll improve on this with a good implementation going forward.
+1 on the general idea of encoding the distro/release version in ways to make things clear.
It seems possible that we’ll want to have different GNOME versions provided by content snaps (eg, 3.24, 3.22, 3.18, etc). It seems probable that we’ll want to have each GNOME version built on different releases. Eg, 3.24 for 17.10 and 16.04, 3.18 for 16.10 and 16.04, etc.
That said, I think it would be interesting to work through different yaml examples (perhaps you already did this… Maybe we’ll NAK all of these, but at least they will have been discussed :). @niemeyer, if I didn’t capture the yaml/cli experience you were thinking of down below, can you respond with your ideas?
‘16-10’ implies Ubuntu 16.10, which on the surface feels a little weird if considering the long tail of things. Will ‘26’ imply Fedora 26? That said, since this is only a short-term solution (we don’t even have alternate bases yet), maybe it doesn’t matter?
Eg, consider the following snap.yaml for the GNOME content snap which I think is what you proposed in the video (please correct me!):
name: gnome-16-10
version: 3.24
slots:
gnome:
content: gnome-16-10
...
which yields the following cli experience (for a manual connection):
$ snap install gnome-16-10
$ snap install foo
$ snap connect foo:gnome-16-10 gnome-16-10:gnome-16-10
It isn’t clear that gnome-16-10 contains gnome 3.24 (which, granted, the user doesn’t technically have to care about, and the version can be obtained via snap info gnome-16-10) and there is a lot of ‘gnome-16-10’ in the connect command. Lastly, it means that we can’t have both a GNOME 3.24 ‘gnome-16-10’ snap and a GNOME 3.18 ‘gnome-16-10’ snap installed at the same time.
Perhaps it was your intent to convey that the gnome-16-10 snap contains not only the libc, libgcc, etc from 16.10 but also be the GNOME runtime that was included in 16.10 (therefore, gnome-16-04 contains GNOME 3.18, gnome-16-10 contains GNOME 3.20 and gnome-17-10 contains GNOME 3.24)?
For sake of the conversation, here are some alternate examples (I found it helpful to work through developer/user experiences like this):
name: gnome-3-24
version: 3.24.2
slots:
16-10:
content: 16-10
16-04:
content: 16-04
then the experience becomes:
$ snap install gnome-3-24
$ snap connect foo:16-10 gnome-3-24:16-10
This does convey the 3.24-ness of the snap, but because the name is ‘gnome-3-24’, it means it must be artificially large to contain different distro/releases (since we aren’t using tracks in this example).
name: gnome-16-10
version: 1.2.3
slots:
gnome-3-24:
content: gnome-3-24
gnome-3-18:
content: gnome-3.18
This is a big content snap that clearly shows it has 16-10 compatible contents and it contains different GNOME versions. The experience then is:
$ snap install gnome-16-10
$ snap connect foo:gnome-3-24 gnome-16-10:gnome-3-24
This is pretty clear and similar to the suggested yaml (AIUI). It allows for different distro/release snaps to be co-installed. It allows for the distro/release to contain different GNOME versions if desired, but that isn’t a requirement.
Encode the GNOME version and the distro/release in the name:
name: gnome-3-24-16-10
version: 1.2.3
slots:
16-10:
content: 16-10
Experience:
$ snap install gnome-3-24-16-10
$ snap connect foo:16-10 gnome-3-24-16-10:16-10
That’s a pretty terrible name and awkward cli experience.
Some of the yaml above somewhat addresses multiple GNOME versions and distro/releases, but is space-inefficient (“why should I need to download 3.18 with 3.24 if all the snap needs is 3.24?”). As such, it seems we could possibly utilize tracks to help with this, but I’m not sure what would be the best way.
Perhaps create a 3.24 track for gnome-16-10:
name: gnome-16-10
version: 3.24
slots:
3-24:
content: 3-24
and a 3.18 track for gnome-16-10:
name: gnome-16-10
version: 3.18
slots:
3-18:
content: 3-18
then the experience is:
$ snap install gnome-16-10 --channel=3.24/stable
$ snap connect foo:3-24 gnome-16-10:3-24
This doesn’t help with having GNOME 3.24 and 3.18 co-installable for 1610.
Or, use channels for ‘gnome-3-24’ snaps. Eg, can create a 16.10 channel:
name: gnome-3-24
version: 3.24
slots:
16-10:
content: 16-10
then:
$ snap install gnome-3-24 --16.10/stable
$ snap connect foo:16-10 gnome-3-24:16-10
This allows different GNOME versions installed, but you can’t have, for example, gnome-3-24 for both 16-04 and 16-10 installed at the same time.
I’m not sure which experience is best (maybe alternate #2, since it is basically the suggested idea with the option of having more GNOME versions inside…), but it seems that some of the criteria should be:
Note that the second :gnome-16-10 is unnecessary. This works:
snap connect foo:gnome-16-10 gnome-16-10
I’ve tried to respond to that question in the video: this is not about Ubuntu, but rather about a way to label the set of traits that the snap depends upon before there’s a more formal way to do that. We could end up creating a gnome-17-08 if we had to, for a set of constraints that were never seen in Ubuntu.
It should be very clear, just like it’s clear for every other snap: there’s a version field! snap info, snap list, etc, will all tell you what the version for the snap is. What we’re discussing here is the snap name, which in most cases doesn’t have to (and should not) contain a version field in it.
This is a non-starter. It’s a global namespace… we’ll never allow a snap to publicly offer “16-10” alone.
This is the original proposal in this thread and the video explains the issues on it.
We already have a version field. There’s no need to put the version both in the name and in the field.
We don’t allow to install multiple instances of same snap today, and we don’t allow a snap to declare which track of a different snap is the default provider. Also suffers from the global namespace issue described above.
Same as above.
I realize gnome-16-10 isn’t meant to convey Ubuntu, but the traits that make it ‘16-10’ come from somewhere. Maybe I got hung up on 16-10 because it sounds like Ubuntu 16.10, but what I was thinking about was, if the snap is built from the Ubuntu 17.10 archive and we label it ‘17-10’, and another snap is built in October 2017 from Fedora toolchain, etc, is 17-10 may not be a good enough label since the Fedora October 2017 toolchain/etc and the Ubuntu 17.10 archive’s toolchain/etc may not be the same, but the label seems to apply equally to both.
Again, this might not be something to worry about a ton right now since this is only meant to be a shrot-term solution, but I wanted to call it out.
Sure. There is one issue with it that I didn’t hear discussed in the video. This issue might not be something we care about, but wanted to make sure it was thought about. The issue is if the snap is named gnome-16-10 then that of course means that there can be only one of these on the system. As a result, to support multiple GNOME versions (3.18, 3.20, 3.24) with the 16-10 traits on the system at the same time, then the gnome-16-10 needs to be big and contain a ‘content’ slot for each GNOME version or there must be separate content snaps for each GNOME version (which might reintroduce the version in the ‘name’ field to disambiguate them).
Again, perhaps this isn’t a concern since your suggested short term solution is to help the desktop team and they are currently only interesting in GNOME 3.24. Perhaps you were thinking the whole time that one of the ‘16-10’ traits was that it is GNOME 3.24.