Build Snaps on Yocto?

One the major drawbacks of Snapcraft (for me) is, that it cannot provide me, afaik, with a complete set of licenses of all the dependencies that are used to build a snap or are contained in a snap. Therefore, in my company, I may not use any snap provided by Canonical or someone else or cannot even build my own, as during build Snapcraft loads all the neccessary dependencies from some Canonical server (I won’t even talk about my struggles to use snapcraft with our company proxy…).
Despite Canonicals voluminous promises “We help you keep track of the licenses you depend on.” snappy is basically useless when going to production, at least in our company.
A snap build via Snapcraft would never survive our open source clearing.

We have used Yocto in some prior projects, and Yocto CAN provide a complete list of all the used open source software used and can even integrate license texts or source code into a package or image, if required by a license used during build.

So the best solution might be, to use the Yocto build framework to build a snap.
There is already a Yocto recipe to build snapd for Yocto. Perhaps someone already tinkered around to use Yocto to build a snap?
Are there perhaps any endeavours under way at Canonical?



$ sudo find /snap/ -name '*copyright*'|wc -l

my installed snaps definitely ship their license files for the dependencies installed by snapcraft inside the snaps … indeed for bits built from source the snap maintainer is responsible to include these additionally …

I think you mean using Yocto to build a base snap? Similarly, to Ubuntu Core, Freedesktop runtime (Base runtime freedesktop-sdk-runtime-19-08) and (Fedora 29 base snap, demoed last year).

If so, feel free to ping me. I’d be interested in helping out. Might even push some patches in time for 2.8 release.

Building a bootable base on Yocto is something completely different though.

Yes, a base snap or generally any application that can be build with Yocto to package it as a snap.
Basically Yocto and Snapcraft are quite similar, both use a description file to pull in sources, fetch or build dependencies inside a closed-off environment, build and package the application and provide any build artifacts for further build processes in a staging area.
From a Yocto point-of-view everything needed to bundle an app as a snap is already there, it just needs to be packaged in the snap format.
With Yocto I can specify as a last step how the image should be bundled, as an tar.gz, .iso, docker, whatever.
Should be doable to also wrap an application and its dependencies in a snap-squashfs-thingy.

That’s true, but if that chain is broken somewhere… I have to trust the maintainer blindly that everything is okay.
As each snap ships its snapcraft.yaml, I could pull the sourcecode used for the snap and check for oss, but I can’t tell where the dependencies, which are pulled in as binaries, originate from.

well, the snapcraft.yaml shoud pretty clearly tell you …

if you simply include “stage-packages”, these things definitely come from an ubuntu archive (either 16.04 or 18.04, depending if your snapcraft.yaml uses a “base:” keyword (and which one)) …

if you dont use stage-packages but something else, this specific “something else” has to be described in the snapcraft.yaml (wget some binary from sourceforge, build from upstream source etc) … it is admittedly a lot harder than just looking at a “licensefiles.txt” list or whatnot because you need to do some reverse engineering forensics based on snapcraft.yaml but you can definitely find out if everything in a snap is legal and where the single bits come from when investing a bit of work.

Note that not all snaps ship a snapcraft.yaml in the snap, the env variable SNAPCRAFT_BUILD_INFO must be set to 1 for a snapcraft.yaml to be included in the built snap. I believe that environment variable is set by default in build environments like launchpad et al, but just running snapcraft on my machine doesn’t include the snapcraft.yaml in the built snap.

Also note a common thing you would want to look at would be the source specifications for the parts in the snapcraft.yaml, but as @ogra says there could be more complicated builds where the “real source” is in an override-build snippet that uses wget somewhere, etc.