Snapcraft has unclear behavior when providing same build-snap from different channels
Metadata
Current evaluation
Conflicting build-snap channels can install stable instead of an explicitly requested candidate; maintainers acknowledged the ambiguity, but no fix or conflict-resolution policy is recorded.
Suggested action: keep open
Reason: Maintainer lengau confirmed that bindgen requested bare llvm-chromium while chromium requested llvm-chromium/latest/candidate, and noted that the installation log hid which channel won. The reported build log provides a concrete failure, but implementing a warning or failure policy for unqualified and conflicting channel requests still requires design and test coverage.
Evaluated by: mr-cal-bot
Impact:
47
Quick Win:
16
Complexity:
51
Confidence:
91
Actionability:
70
Issue body
Chromium beta has a dependency on llvm-chromium/candidate.[1]
Currently, these are its releases in the Snap Store:
--->
% snapcraft status llvm-chromium
Track Arch Channel Version Revision Progress
latest amd64 stable 20 22 -
candidate 21 27 -
beta ↑ ↑ -
edge ↑ ↑ -
arm64 stable 20 24 -
candidate 21 25 -
beta ↑ ↑ -
edge ↑ ↑ -
armhf stable 20 23 -
candidate 21 26 -
beta ↑ ↑ -
edge ↑ ↑ -
<---
The log of recently failed Chromium builds indicate that the Store was providing Llvm-chromium from the stable channel rather than from candidate. For example, for Armhf, the log[2][attached] contains this piece of debugging information:
--->
:: + find / -name '*libclang_rt*'
:: /snap/llvm-chromium/23/lib/clang/20/lib/armv7-unknown-linux-gnueabihf/libclang_rt.builtins.a
<---
The path element /23/ demonstrates the snap is coming from the stable channel, contrary to specified in snapcraft.yaml.
This failure was also affecting Amd64, which I wanted to unblock, so I tried
snapcraft release llvm-chromium 27 candidate
, which should be a no-op as that is already the revision in the candidate channel of Amd64, but then a retry on the failed Amd64 build completed successfully.
I decided to preserve the Armhf failed build as evidence of this behavior. Interestingly, the issue did not affect Arm64.
[1]https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/tree/snapcraft.yaml?h=beta#n168
[2]https://launchpad.net/~chromium-team/+snap/chromium-snap-from-source-beta/+build/2759958
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
47
Quick Win:
16
Complexity:
51
Confidence:
91
Actionability:
70
|
keep open | Conflicting build-snap channels can install stable instead of an explicitly requested candidate; maintainers acknowledged the ambiguity, but no fix or conflict-resolution policy is recorded. | |
| stealth/space-bunny-alpha |
Impact:
45
Quick Win:
17
Complexity:
48
Confidence:
88
Actionability:
72
|
keep open | Conflicting part-level build-snap channels can install stable llvm-chromium instead of candidate, causing intermittent Chromium build failures; maintainers acknowledge the ambiguity. | |
| stealth/space-bunny-alpha |
Impact:
48
Quick Win:
13
Complexity:
62
Confidence:
84
Actionability:
72
|
keep open | Conflicting build-snap channel declarations can install llvm-chromium from stable instead of candidate, causing intermittent Chromium build failures; the behavior is acknowledged but unresolved. | |
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
14
Complexity:
62
Confidence:
69
Actionability:
65
|
needs triage | Chromium builds appear to receive llvm-chromium/candidate from stable; rerunning after a no-op candidate release succeeded, while arm64 was unaffected. No maintainer triage. | |
| qwen3.6-35b-a3b-mtp-q6 |
Impact:
60
Quick Win:
33
Staleness:
85
Complexity:
45
Confidence:
55
Support Request:
15
|
needs triage | Bug report: snapcraft resolves build-snap from wrong channel (stable vs candidate). Untriaged, no maintainer response in 527 days. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
45
Confidence:
80
Support Request:
15
|
needs triage | Snapcraft fetches build-snap dependencies from the wrong channel when identical revisions exist across multiple channels. Currently unlabelled, awaiting maintainer triage, and inactive for over a year. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
92
Complexity:
55
Confidence:
78
Support Request:
20
|
close stale | Snapcraft incorrectly resolves build-snap dependencies to the stable channel instead of the specified candidate channel during builds. Untriaged, inactive for 16 months with no maintainer response. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
40
Confidence:
70
Support Request:
10
|
needs triage | Snapcraft incorrectly resolves build-snap channels when revisions overlap, pulling stable instead of candidate. Unassessed after 15 months with zero maintainer interaction. |
Update history
| Date | Change |
|---|---|
| created |
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1636979 snapcraft validate and sign-build are inconsistent when there are multiple keys | snapcraft (launchpad) | open | Snapcraft validate silently uses the default signing key while sign-build prompts with multiple keys; the inconsistency is reproducible, but no resolution or maintainer decision is recorded. | |
| #1621713 snapcraft release doesn't match the spec | snapcraft (launchpad) | closed | Snapcraft now correctly handles revision arguments and channel updates; the maintainer confirmed the outdated release behavior is resolved. | |
| #2020683 snapcraft remote-build cannot use a custom version of snapcraft | snapcraft (launchpad) | closed | Closed as stale without a fix. A maintainer said Snapcraft developers could tap channel branches; later channel-selection work remains open in canonical/snapcraft#6384. | |
| #1893850 Snapcraft doesn't inject itself into build VM if host rev doesn't change | snapcraft (launchpad) | open | An old, unlabeled report says sideloaded Snapcraft snaps with identical x1 revisions can leave a stale build-VM copy; the tracker has no follow-up or confirmed hash-based fix. |