Architectures

doc
22

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

image
image373×892 36.2 KB

23

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

1 Like
24

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.

2 Likes
25

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?

26

Here’s an example:

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

27

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.

3 Likes
28

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

1 Like
29

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.

3 Likes
30

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?

31

Looking at the version/channel dropdown in Install gnome-46-2404-sdk on Linux | Snap Store, the gnome extension for core24 has the same support as core22: amd64, arm64, and armhf.

I think we need to update https://snapcraft.io/docs/gnome-extension to include core24 and the list of supported architectures.

1 Like
32

I suspect there is a typo in the last sentence of the doc:

- a snap built for armhf can stage amd64 packages.
+ a snap built for armhf can stage arm64 packages.

I don’t think armhf snap can natively stage amd64 packages.

33

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 :slight_smile: