inconsistent to arch behaviour
Metadata
Current evaluation
Snapcraft 3.6 stage-packages with 'on <arch>'/'to <arch>' conditionals behave inconsistently: cross-compiling works but native builds fail to pull required packages, and adding 'else' under 'on amd64' mixes arch packages. No maintainer response in 7+ years.
Suggested action: needs triage
Reason: The issue has zero comments, no labels, and no maintainer interaction in 2613 days (~7 years), reported against snapcraft 3.6. It describes a genuine bug in architecture-conditional stage-packages resolution (native builds not pulling packages, mixed-arch pulls with 'else'), which is a real correctness problem in the parts/lifecycle architecture handling. However, it is extremely old and snapcraft has undergone major rewrites since 3.6, so it needs triage to determine whether the behavior still reproduces on a current version before any fix or close decision.
Impact:
55
Quick Win:
16.5
Staleness:
95
Complexity:
70
Confidence:
55
Support Request:
15
Issue body
snapcraft version: 3.6
Inconsistent behaviour when -to <arch> is used for stage packages
Behaviour this feature is unpredictable and inconsistent least to say as examples demonstrate
Following works correctly when cross compiling on amd64 to arm
stage-packages:
- on amd64:
- to armhf:
- iproute2:armhf
- netplan.io:armhf
- systemd:armhf
- to arm64:
- iproute2:arm64
- netplan.io:arm64
- systemd:arm64
- else:
- iproute2
- netplan.io
- systemd
however it magically fails when building natively as it does not pull in required packages (tested on amd64 and arm)
Further more adding - else statement under 'on amd64' breaks even arm cross build on amd64 as it pulls portion of the packages for arm and other portion for amd64
stage-packages:
- on amd64:
- to armhf:
- iproute2:armhf
- netplan.io:armhf
- systemd:armhf
- to arm64:
- iproute2:arm64
- netplan.io:arm64
- systemd:arm64
- else:
- iproute2
- netplan.io
- systemd
- else:
- iproute2
- netplan.io
- systemd
Attempt to use more generic definition like following:
stage-packages:
- to armhf:
- iproute2:armhf
- netplan.io:armhf
- systemd:armhf
- to arm64:
- iproute2:arm64
- netplan.io:arm64
- systemd:arm64
- to amd64:
- iproute2:amd64
- netplan.io:amd64
- systemd:amd64
This actually works well when cross building, but fails spectacularly when building natively as it does not pull in required packages
All around using 'on <arch>' or 'to <arch>' seems to produce highly unpredictable results
test snap build here
https://launchpad.net/~ondrak/+snap/netplan-test
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
16.5
Staleness:
95
Complexity:
70
Confidence:
55
Support Request:
15
|
needs triage | Snapcraft 3.6 stage-packages with 'on <arch>'/'to <arch>' conditionals behave inconsistently: cross-compiling works but native builds fail to pull required packages, and adding 'else' under 'on amd64' mixes arch packages. No maintainer response in 7+ years. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
40
Confidence:
90
Support Request:
10
|
close stale | Snapcraft 3.6 stage-packages arch filtering behaves unpredictably during cross-compilation vs native builds. Unlabelled, zero comments, 7 years old. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
30
Confidence:
90
Support Request:
10
|
close stale | Reports inconsistent behavior of the -to arch flag for stage packages in Snapcraft 3.6. The issue has seen no activity in over 7 years and references a severely outdated version. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
98
Complexity:
30
Confidence:
90
Support Request:
10
|
close stale | Inconsistent behavior with snapcraft's stage-packages architecture targeting (-to/on arch) in v3.6. Cross-compilation works but native builds fail. Zero maintainer activity for 7 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
40
Confidence:
90
Support Request:
10
|
close stale | Unpredictable snapcraft -to <arch> stage package selection during cross-compilation and native builds. No maintainer response or labels after ~7 years. |
Update history
No update history recorded yet.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2012503 wrong arch of stage packages | snapcraft (launchpad) | open | Snapcraft 7.3 picks host architecture for stage packages when cross-building (build-on amd64, build-for arm64). No maintainer response in 3.4 years. Nearly identical issue #5335 was closed as expected behavior requiring explicit :$CRAFT_ARCH_BUILD_FOR suffix on stage packages. | |
| #2061603 snapcraft 8.1 core24 root build-packages with "on <arch>" fails | snapcraft (launchpad) | closed | The on <arch> syntax in root build-packages fails parsing in snapcraft 8.1/core24. Closed and abandoned without resolution. | |
| #1881515 Snapcraft pulling wrong arch of debs when building foreign snaps | snapcraft (launchpad) | open | 2018 report: --target-arch=armhf on x86 pulls x86-64 stage-packages debs instead of armhf. No labels, comments, or maintainer response in 6+ years. Legacy --target-arch flag removed; modern cross-compile documents the :$CRAFT_ARCH_BUILD_FOR suffix requirement. | |
| #1885074 stage-packages behaviour inconsistent | snapcraft (launchpad) | open | Snapcraft 4.0.7: stage-packages with :arm64 suffix cross-compile fine but native arm64 build yields an empty snap. Reported ~6 years ago, no maintainer response, no labels, zero comments. | |
| #1813634 not reliable way to detect target architecture | snapcraft (launchpad) | open | Snapcraft 3.0.1: project.target_arch and SNAPCRAFT_ARCH_TRIPLET give inconsistent values for target arch across native, cross, and multi-arch (build-on/run-on) builds. No maintainer response, no labels, inactive ~7 years. |