RFC: Ubuntu Seeded Snaps

Colin Watson cjwatson at ubuntu.com
Fri Feb 9 10:00:28 UTC 2018

On Fri, Feb 09, 2018 at 09:37:17AM +0000, Robie Basak wrote:
> On Thu, Feb 08, 2018 at 03:10:08PM -0800, Steve Langasek wrote:
> > Snaps included in images will be installed referencing a per-Ubuntu-series
> > branch.  This ensures forwards-compatibility by allowing publishing to this
> > branch if the mainline of a snap becomes incompatible with a given Ubuntu
> > release, without requiring up-front maintenance of multiple snap channels.
> I don't follow this. Are you suggesting that the seed list a snap
> version number? Or a specific code branch in Launchpad from which the
> snap ending up in the images will get built? If the former, wouldn't the
> install base become "stuck"?

Store channel names are formed as [track/]risk[/branch]; it's this kind
of branch that Steve is referring to.  (The spec should probably just
say "channel", though.)

I'm not sure how this can avoid requiring up-front maintenance of
multiple snap channels.  If the proposal is that we install snaps in a
way that will cause refreshes to pull from a pre-configured per-series
channel, then unless that channel actually exists then "snap refresh" is
surely going to be returning errors, which doesn't seem like a good
stock configuration.

This raises another point; when upgrading to versions beyond 18.04,
users' systems will need to be modified to follow the appropriate
per-series channel for each of these preinstalled snaps.  Somebody will
need to teach the upgrader to do this, and it will also need to be
documented for people who don't use update-manager/do-release-upgrade.

> I'm very much in favour of the above two requirements, but there's also
> a little more. With the current archive, these are some existing
> properties that I think should be considered for inclusion in this
> policy.
>  * _Users_ (rather than just developers) can retrieve the full source
>    associated with a package from Launchpad with no other external
>    dependencies and rebuild it themselves, and tooling exists for this.
>  * Users can find the build logs associated with every binary shipped
>    from the archive.
>  * The above two statements are true both for packages that a user is
>    considering installing but has not yet installed, and for packages
>    that a user has installed locally.
> Does any of this exist with snaps today (that were built from source on
> Launchpad)? I haven't been able to find any suitable connection to
> identify the provenance of a snap in this way.

If they were built on Launchpad with the proposed changes to disallow
external network access, then all the necessary information exists, but
there's currently no tooling to help users actually find it.

Colin Watson                                       [cjwatson at ubuntu.com]

More information about the ubuntu-devel mailing list