Not sure why, but the ToC on the published version only shows the level-2 headings, which isn’t helpful:

Thanks for the screenshot and for letting us know. I’ve incremented all the headings, which should fix the problem.

1 Like

Is there any rationale for this change? There’s nothing obviously different about core24 at the snapd level, so is this just a Snapcraft limitation?

We’re shipping an architecture: all snap in the default Ubuntu install, so it seems weird to remove this feature.


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?

Here’s an example:

Building for every architecture will work, but is wasteful and requires tracking any changes to the supported architectures.

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:

  1. We only need to build it once rather than 6 times, and avoid running builds on the slower architectures.
  2. We know the exact same data will be provided on all architectures, since they’ll be using the same snap revision.
  3. 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.


Thanks @alan_g and @jamesh, we created some tasks and have started working on this:

1 Like

build-for: [all] is now supported for core24 snaps in Snapcraft 8.3.1.

8.3.1 also adds support for build-for: [all] for core22 snaps for the remote builder.