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.