content snap dependency management

[Jonathan Riddell]

In KDE land we are creating Snaps for KDE Applications. These all use Qt and KDE Frameworks which is a lot of duplicated disk space if included in every Application. So we have split these out into an isolated snap kde-frameworks-5. However this must be installed prior to the application else it doesn't work.

snapd should include a method of dependency tracking for when snaps need another snap installed first.

[Mark Shuttleworth (sabdfl)]

Agreed, this is a priority to make a great desktop experience.

At the moment I've seen two paths discussed:

  * stacks (where the name being installed is a YAML description of a
set of snaps and plugs connecting them)
  * deps (where the store knows to send the extra snap and the device
knows that's OK)

In both cases the user should just ask for what they want ("snap install
krita") and everything else Just Works.

Thoughts?
Mark

[Gustavo Niemeyer (niemeyer)]

The specification for the content interface already includes the definition of a "default-provider" setting which may be set to the name of a snap that will be installed if no other snap in the system can satisfy that specific content interface.

Please note that in such cases where the snap holds binary data and other implicit dependencies, the snap name and the content interface label should really include an identifier that uniquely defines the content in it. For example, I would suggest something like "kde-5-1604" for a content snap shipping all the KDE libraries that are compatible with Ubuntu 16.04.

If you're interested, I've explained in more detail that problem in the following whiteboard session. Please just note that the name there will likely change from "gnome-16-04" to "gnome-3-24-1604" similar to what was suggested above with "kde-5-1604". https://youtu.be/KEm5WNsAnbE

[Gustavo Niemeyer (niemeyer)]

Sorry, I forgot to mention that despite being in the spec for a while the "default-provider" is not being installed yet, but Michael has been working to fix that in the last couple of days.

[Aleix Pol (aleixpol-kde)]

Bump?

[Michael Vogt (mvo)]

I started looking into this and pushed some preliminary code to https://github.com/snapcore/snapd/compare/master...mvo5:default-plugin-provider?expand=1 - however we will need support from the store to expose the "plug/slot" information from the details json.

[Michael Vogt (mvo)]

This is being worked on in https://github.com/snapcore/snapd/pull/4103

[Ads20000 (ads20000)]

This is fixed since snapd 2.32 https://github.com/snapcore/snapd/commit/aab465d34d1cf41c0b57f2991d49c69076624f81

I think it needs more work, however: https://forum.snapcraft.io/t/give-more-useful-info-for-installing-content-snaps-than-automatically-connect-eligible-plugs-and-slots-of-foo/5414