Are snaps suitable for packaging versioned embedded toolchains?

snap
1

We need to distribute custom embedded toolchains to developers and build-machines. These usually consist of a combination of parts:

  • compiler toolchain(s) - think all of the gcc/gdb compiler suite + libraries aka crosstools. These need to be available as command-line tools and can comprise easily 50-odd command-line executables that expect to find their support files (libraries and headers) in a relative location
  • GUI tools (eg IDEs) - commonly these are based on java, QT or might package a modified version of eclipse. The versions here are without exception at least 2-4 years old, commonly with deps like QT4. Build machines don’t need the GUI tools.
  • n specific components - for example support for a single target configuration, of which there might be many - it might be nice to only install the ones of these they you need. For this discussion just consider that these are a bunch of directories of support files, that if present provide extra targets inside the compiler toolchains and/or UI, but are optionally not present

In some cases these may only be available as x86 or combinations of x86 and x86_64 binaries. In almost all cases they will contain some hard-coded install paths. Additionally the sum total of a single toolchain version will typically consume ~1-40GB of space (its grotesque).

The final “base requirement” is that each project or release of a product is delivered against a single version of toolchain, and that changing for a released product is not possible/desirable. Development and support activities must continue on both old and new toolchain versions so it must be possible to install more than one version at a time.

Currently we distribute these as .deb packages. This has to subvert the versioning system to install different versions side-by-side. So we have package-1.0_1.0-1.deb. This works fine for the compilers, and OKish as long as the OS version supports the required library dependencies, but need to be repackaged every time a new (LTS) release migration is attempted, and we are finding that most won’t be able to be supported on 20.04 as old lib packages drop out (python2, qt4, x86, etc,…)

.deb handling of the different parts and components is performed by simply installing in the final location (on a VM), then dividing the resulting directories into different debs. So when the packages are installed each finds the files installed exactly where it expects it - hard-coded paths and all.

Reasons why snap seems appropriate:

  1. Satisfying GUI lib requirements gets harder - 18.04 is about the golden limit in terms of lib support, but we don’t want to be chained to 18.04 forever (hint - we only just managed to update to 18.04 in the last month). So core18 looks good to me.
  2. Support for x86 code (libs) also peaks with 18.04 and declines later
  3. Toolchains may ship their own ancient versions of libraries which should be segregated from system
  4. Snaps support versioning
  5. debs have issues dealing with packages larger than 2GB (.deb size) and ~10GB (uncompressed size)

Reasons why I think snaps won’t/can’t work

  1. Need to export a huge number of command-line tools. The task of identifying each exported command-line tool into the .yml seems like a huge burden. Its not clear if wrappers to snap command-line tools will break the relative lookups for finding related libraries. Is there another way to make command-line tools available from snaps - I don’t find any examples of this.
  2. Its not clear to me if composing multiple snaps together would help to split these pacakges up (eg UI depends on compiler tools, compilers want to see which component packages (snaps) are installed) . Are there examples anywhere like this?
    1. If I understand the documentation only “extensions” are able to compose snaps on top of each other - are these specially “blessed” packages, or an any packages be stacked?
  3. Can snaps handle such huge sizes 2-5GB seems to be the smallest I can divide some components up into - obviously I wouldn’t be uploading huge sizes to the store
  4. Can multiple versions of the same snap be installed and used at the same time? Does this interact with command-line tools exporting?

I’m going to stop there because this is already long enough. Is my understanding of now snaps would (or would not) work accurate?