Base runtime freedesktop-sdk-runtime-19-08



I would like to request review for a base runtime. This is the runtime that is used for flatpak and we would like to allow application developers to build

I have posted details on previous post:

We plan for the next release to be done in August 2019, thus the name. For the moment we are trying to push edge builds in order to test the upcoming release.

Thank you.


Thanks for the request. Please bear with us since this is one of the first requests for a base snap.

According to Process for reviewing base snaps, the name of this snap, freedesktop-sdk-runtime-19-08, is valid (though the examples suggest freedesktop-sdk-runtime-1908, I don’t believe that is a blocker). As such, this seems a reasonable candidate. Since this is one of the first community base snaps, I’m going to ask @pedronis to review Process for reviewing base snaps and this snap to ensure we have captured all the requirements.

In terms of vetting, Valentin appears to be a member of freedesktop-sdk which IMO is suitable for this base snap; @advocacy, can you verify this and perform any additional vetting (eg, as we might do for globally connected content snaps or classic-- since a base snap places a lot of implied trust by consumers in the provider’s publisher). @pedronis, is there any vetting criteria you’d like to see met? Perhaps a collaborators feature or something more official than Valentin’s personal email address?

When this is all done, I’ll generalize the requirements and update our processes accordingly.

@valentind - thanks again for your snap and working with us :slight_smile:


I am not sure how this works. Do I need to do something to create a project account?


Let’s wait on @advocacy and @pedronis to respond.

@advocacy and @pedronis - ping


I was on vacation when this started. This is on my queue now but it will take me a little while to get back to it, sorry.


Gentle ping, I know you are sprinting this week; just making sure it stays on your radar.


Sorry it took me a while to get back to this, not lack of interest or support, but bad timing with vacation and planning events…

Yes, 1908, no hyphen, would be more typical.

Related to this, it’s important to remember that what is being setup here is a contract between the base and the snaps using it: after a base snap is in stable any backward incompatible changes to API/ABI or removing any file that would have been accessible given the default apparmor template or relevant interface ones would be a break of that contract.

  • A base runs with as much confinement as the snaps using it, OTOH for example libraries related to networking in it could capture data and send it somewhere else. This means, I would think, some level of publisher vetting similar to classic would be appropriate, I would say it’s much preferable if a base is maintained by a community or project than an individual.
  • A base needs to contain empty directories for anything that snap-confine doesn’t create but mounts over.
  • I would imagine that a base might contain files with permissions etc that are outside what we allow for app snaps, that will need exceptions, special considerations.
  • If the base needs to expose files that are not allowed by the base template, hopefully not, we need to think what to do.

That’s the first set of things that came to my mind.

Also @valentind, given that we don’t have and didn’t expect many bases ATM so we punted on non ad hoc approach, I think you’ll have to discuss with @sergiusens how to make sure snapcraft knows how to get appropriate build images corresponding to the base.


This should not block experimentation or the initial build up though. What is the timeline for this? I would like to take the opportunity to work on documentation while go through this procedure.