Okay, so here is an alternative naming that covers the concerns explained in the video and supports that:
gnome-3-24-1610
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?
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?
Per notes above and in the explanation in the video, we need the name in the content interface as otherwise anything can connect to anything else, compatible or not.
Importantly, we are allowing auto-connection of the slot with ‘content: gnome-3-26-1604’ when the plugging snap’s ‘content’ field matches the slot.
(Also using a one element list to make it easier for the store reviewer to add another slot in case the snap adds additional content slots, but that isn’t important for this conversation).
it’s not clear to me where and how to utilise this. You say that “we are allowing auto-connection of the slot with ‘content: gnome-3-26-1604’ when the plugging snap’s ‘content’ field matches the slot.”. So what should our snapcraft.yaml look like? Do we need to make it match your yaml in the immediately preceding post, or is that yaml from some other place?
Currently I’ve defined in corebird’s snapcraft.yaml:
The latter explicitly declares the ‘content’ attribute of the plugged content interface. This is what must match for auto-connection. The former is a shorthand where the ‘content’ attribute isn’t specified, so the name of the plug is used for ‘content’ (so in that case, the name of the plug must match for auto-connection).
I add the gnome-3-24-platform plug in the app section and also set after: [desktop-gnome-platform] in parts. Now if I just change the plug declaration to the gnome-3-26-1604 example above the snap will build, but on installation it still complains about the need to connect to gnome-3-24 since desktop-gnome-platform seems to rely on that.
Am I doing this wrong? Is there an updated version of desktop-gnome-platform needed or do I even need this at all?
In general I find it hard to find any info on this, the only thing having at least some documentation on using the content snap is https://wiki.ubuntu.com/snapcraft/parts, and even this is not very clear.