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?
I’ve created a new snap for GNOME 3.26 named gnome-3-26-1604 (in edge channel). I’ve also dropped the redundancy in the slot name.
snap connect foo:gnome-platform gnome-3-26-1604:gnome-platform
How does that sound?
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.
OK, that makes sense. I’ve renamed the slot to include the versions.
snap connect foo:gnome-3-26-1604 gnome-3-26-1604:gnome-3-26-1604
+1 to auto-connect that one.
+1
Granted auto-connection for this snap when the plugging snap’s ‘content’ field matches the slotting snap’s ‘content’ field. This is live now.
@niemeyer and @kenvandine, since this is the first one of these with the new process, I want to be clear that the snap declaration is:
slots:
content:
allow-auto-connection:
-
plug-attributes:
content: $SLOT(content)
slot-attributes:
content: gnome-3-26-1604
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:
plugs:
gnome-3-24-platform:
interface: content
target: gnome-platform
default-provider: gnome-3-24:gnome-3-24-platform
Do I need to change that to just reference the new gnome-3-26-1604 snap? If I do would it look like:
plugs:
gnome-3-26-1604-platform:
interface: content
target: gnome-platform
default-provider: gnome-3-26-1604:gnome-3-26-1604-platform
Or do I need to know some other incantation?
That yaml is snap declaration yaml, not snapcraft yaml (which is why I pointed this out to an architect and the requesting publisher, not everyone).
Your existing yaml is close. This is what you need:
plugs:
gnome-3-26-1604:
interface: content
content: gnome-3-26-1604
target: gnome-platform
default-provider: gnome-3-26-1604
The important thing is that you do either:
plugs:
gnome-3-26-1604:
interface: content
or:
plugs:
something:
interface: content
content: gnome-3-26-1604
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).
See:
Speaking of which, @kenvandine, it looks like https://wiki.ubuntu.com/snapcraft/parts is out of date and needs to be updated for the gnome-3-26-1604 content snap.
gotcha, thanks 