content snap dependency management

Bug #1711329 reported by Jonathan Riddell on 2017-08-17
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd
High
Michael Vogt

Bug Description

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.

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) wrote :

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) wrote :

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.

Changed in snapcraft:
status: New → Confirmed
importance: Undecided → High
status: Confirmed → In Progress
assignee: nobody → Michael Vogt (mvo)
Aleix Pol (aleixpol-kde) wrote :

Bump?

Michael Vogt (mvo) wrote :

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.

Kyle Fazzari (kyrofa) on 2017-11-20
affects: snapcraft → snapd
Michael Vogt (mvo) wrote :
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers