Sorry, what I meant was: you can have a snap that has architectures: [amd64, i386] that would end up being the same blob on either of those architectures, and it would need to have the smarts to figure out which binaries it needs to use in each case (you might want this for example if you want to support tracing a 386 binary on amd64). Or you can have architecture-specific revisions, that is, if you’re on amd64 you only get the amd64 builds. Both are possible.
I just noticed you said
I’m hoping that’s a typo, as 1. it’s architectures, not architecture; and it’s snapcraft.yaml, not snapcraft.yml.
If you give the architectures spec a read
You’ll see that example 6 says that
architectures: [ i386, amd64 ]
is the same as
architectures:
- build-on: [amd64, i386]
run-on: [amd64, i386]
which means “if building on amd64 or i386, the resulting snap will work on amd64 and i386”. This is probably not what you want.
Also in particular from this note
you’ll notice that what you’re saying you want is something like
architectures:
- build-on: amd64
- build-on: i386
HTH, HAND.