Snapcraft pulling wrong arch of debs when building foreign snaps

[Taiten Peng]

snapcraft --destructive-mode --target-arch=armhf to build a foreign cpu arch snaps on a x86 machine.

debs specified in stage-packages is not reflecting to the --target-arch=CPU_ARCH when building a snap.

---
Step to reproduce: ( with the attached snapcraft.yaml )
run "snapcraft --destructive-mode --target-arch=armhf"

Expected result:

$> file $SNAP/usr/bin/hello
usr/bin/hello: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=cb9b55fcb9c1b16033fbd3724d0fac693dd346d1, stripped

Actual result:

$> file $SNAP/usr/bin/hello
squashfs-root/usr/bin/hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=4fdca4285732fa8a76721f495e5c5e5295ec237b, for GNU/Linux 3.2.0, stripped

[Chris Patterson (cjp256)]

Have you been able to do this before? I've tested this as far back as 2.43 and it doesn't appear to work...

[Taiten Peng (taitenpeng)]

No I don't, but I thought it should make sense to do so.
I tried on 4.0 and it shows the same result pulling wrong debs as well.

[Chris Patterson (cjp256)]

Taiten, I agree that would make sense :)

However, I talked about it with sergiusens and we are unlikely to change this.

(1) The behavior would change for any existing users.
(2) As you are seeing here, --target-arch support is broken in other ways, and rarely accomplishes what the user is hoping for.

Due to these issues, Snapcraft has disabled --target-arch for core20.

We do understand the value of targeting other architectures, and we hope to provide a well-supported solution in the future.