It hasn’t been deliberately left off, and adding it is certainly something we should do if it’s considered important enough (it is linked to from the snapcraft yaml reference pages).
I think it probably is important enough, but needs a little work (I can do this).
What you’ve listed says that a single build on amd64 will produce a snap that can be used on the three architectures amd64, armhf, and arm64. You probably want something more like:
architectures:
- build-on: amd64
run on: amd64
- build-on: amd64
run on: armhf
- build-on: amd64
run on: arm64
The snapcore/action-build@v1 action does not currently do anything with this information in the snapcraft.yaml. But if you are set up to do cross builds, then you could probably drive it with:
You could either repeat the action three times to perform the three builds in series from a single job, or use the matrix feature to create three parallel jobs.
snapcraft internal error: ValidationError(model='SnapcraftBuildPlanner', errors=[{'loc': ('platforms', 'build-for'), 'msg': 'ensure this value has at most 1 items', 'type': 'value_error.list.max_items', 'ctx': {'limit_value': 1}}])
a snap that is built on arm64 and is built for arm64
a snap that is built on arm64 and is built for armhf
When using a build provider (LXD or Multipass), snapcraft will pack both snaps.
When using --destructive-mode, snapcraft will give you the error:
Multiple builds match the current platform.
Recommended resolution: Check the "--platform" and "--build-for" parameters.
because Snapcraft will only build 1 snap locally (for core24 snaps) and it doesn’t know which of the 2 snaps to build. You need to inform snapcraft which to build with snapcraft pack --destructive-mode --platform arm64.
It’s a snapcraft limitation - no one on the team was strongly opinionated on migrating this feature into core24 and it requires development work to support in snapcraft due to the craft-application integration and with launchpad for remote builds, so it wasn’t prioritized.
That being said, build-for: all could still be added in the future. Can you give us some use cases where building a separate snap for each architecture doesn’t work (or is inconvenient) and links to the snapcraft.yamls where you are using it?
The snap in question is gtk-common-themes. The snap has no apps/daemons/hooks of its own, instead providing architecture independent theme data to other snaps via its content interface slots. It’s been part of the Ubuntu Desktop seed since 18.04.
This is also the model we suggested for people who wanted to package their own themes for use by snaps (all the other gtk-theme-* and icon-theme-* snaps on the store).
I guess the main reasons I’d prefer an architectures: all snap are:
We only need to build it once rather than 6 times, and avoid running builds on the slower architectures.
We know the exact same data will be provided on all architectures, since they’ll be using the same snap revision.
We don’t have to do anything special if a new architecture is added or an existing one removed. The existing revisions will work on the new architecture.
Basically the same reasons you’d use an architecture independent package anywhere else.
I can understand that architecture independent packages might not make sense for some of the other *craft tools, but it is something that is being actively used for snaps. It’s worrying that it was removed without discussion.
build-for: [all] is now supported for core24 snaps in Snapcraft 8.3.1
Sorry cannot find out which architectures are supported for gnome extension in core24.
For core22+gnome it were amd64 arm64 armhf (from full list with amd64 arm64 armhf ppc64el riscv64 s390x) to build on snapcraft resources.
Can you please share which archs can be used with core24+gnome?
It surely can technically (shouldn’t be a prob to pull in any foreign arch packages, no matter which arch they are for), but the usefulness is a bit questionable