@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.
That’s not so different from having a gnome-16-04 being used in Ubuntu 16.10… there’s no big deal really. I see people often using glibc as a similar reference for instance, with packages doing glibc218 or similar, and using it in more recent Linux distributions. It’s a similar idea, except glibc is also just one of the pieces that we need to account for.
Right, exactly. This is gnome-16-04 (or something) version 3.24.
Not sure that’s true, GNOME 3.26 is coming and we are going to want a platform for it so we are likely going to want 3-24 and 3-26 to be available and co-installable. Note that the current 3-24 GNOME comes from 16.10 but that stack was backported to 16.04 in a ppa and the snap is built from that so there is currently no gnome-16-10 (but that probably doesn’t matter for the current discussion)
Okay, so here is an alternative naming that covers the concerns explained in the video and supports that:
That’s similar to @jdstrand’s proposal #3 above, but it drops a dash from the second version number to make it slightly less confusing. I also like the fact it moves away from “16 dot/dash 10” a little bit, making it more of an identifier for the traits depended upon than a version constraint.
Per notes in the video, this would have to be used both in the snap name and in the content interface label.
What’s happening in terms of the auto-connection here? Either we need the snap to auto-connect or there needs to be work in software centers for them to allow the installation of the platform graphically? So that I can link to this WIP in future, what needs to happen for users to be able to use apps that depend on the GNOME platform snap without opening a Terminal?
Yeah i think it needed, not everyone gonna install and open snap from terminal!!
It should be solved.
We need some feedback from the desktop team on the proposal above.
@kenvandine @seb128 @willcooke What’s the status here?
I’m happy enough with the short term solution of the naming schema of gnome-3-24-1604 and gnome-3-26-1604.
One question related to distros, is it implied that snaps in the Ubuntu store are built on the Ubuntu base? Other distros would actually use other stores right?
There are no other stores and there are currently no plans to add support for other stores (because there are many other features that need to take priority). See the discussion here.
Other distros would use their respective base snap …
(once base snaps exist all currently existing snaps will likely be automatically tied to the Ubuntu base snap (which will just be a split of the current core snap AIU) though, new snaps could define to use a different base snap for their respective distro)
@kenvandine There’s no such thing as an Ubuntu Store. What we have is a Snap Store, and the namespace is global. Today snaps are all making use of a core snap which has binaries compiled originally in Ubuntu 16.04, but even that is being opened up, and we’ll have that base snap explicitly defined for each snap. That means people will be able to install a snap based on OpenSUSE binaries in Ubuntu, and vice-versa.
In terms of the connections, can we please go ahead and perform the migration to those names so that we can auto-connect them going forward then?