inconsistent to arch behaviour
Metadata
Current evaluation
Snapcraft 3.6 advanced grammar can omit stage-packages on native builds and mix host/target packages in nested on/to cases; the old report remains open and untriaged.
Suggested action: needs triage
Reason: The report supplies three concrete stage-packages configurations, identifies Snapcraft 3.6 and the affected native and cross-build architectures, and links a test snap for reproduction. It has no labels, assignee, maintainer response, resolving commit, or release, so it still needs triage; its age alone is not grounds for closure.
Evaluated by: mr-cal-bot
Impact:
58
Quick Win:
13
Complexity:
68
Confidence:
87
Actionability:
70
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 |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
13
Complexity:
68
Confidence:
87
Actionability:
70
|
needs triage | Snapcraft 3.6 advanced grammar can omit stage-packages on native builds and mix host/target packages in nested on/to cases; the old report remains open and untriaged. | |
| stealth/space-bunny-alpha |
Impact:
42
Quick Win:
11
Complexity:
63
Confidence:
80
Actionability:
73
|
needs triage | Snapcraft 3.6 stage-package architecture selectors reportedly omit required packages on native builds and mix architectures with nested else; test configurations are supplied but the report has no maintainer triage. | |
| qwen/qwen3.8-27b |
Impact:
55
Quick Win:
16
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. |
Update history
| Date | Change |
|---|---|
| created |
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #2006599 using advanced grammar to build towards a certain arch does not work with stage-snaps | snapcraft (launchpad) | open | Cross-build grammar selects a foreign-architecture stage snap, but its download lacks the target store architecture and reports the snap missing. A workaround exists; the report remains untriaged. | |
| #1885074 stage-packages behaviour inconsistent | snapcraft (launchpad) | open | Snapcraft 4.0.7 reportedly creates an empty core18 arm64 snap when stage-packages use :arm64 suffixes natively, while cross-compilation succeeds; no triage or resolution is recorded. | |
| #2061603 snapcraft 8.1 core24 root build-packages with "on <arch>" fails | snapcraft (launchpad) | closed | Root grammar handling shipped in Snapcraft 8.2.1; mixed grammar/string build-packages remained broken, then was tracked in canonical/snapcraft#4764 and fixed via #4768 (c76e62671). |