Issue a warning when building a snap that stages another snap built on a different base
Metadata
Current evaluation
Request to add a build-time warning when a snap stages another snap built on a different base, preventing runtime AppArmor denials. Open, unlabelled, no maintainer response; only an automated Jira sync comment. Inactive for ~18 months.
Suggested action: needs triage
Reason: The issue is unlabelled and the only comment is an automated Jira-sync bot message (CRAFT-3126) — no maintainer has acknowledged, categorised, or responded to it, so it has not been triaged. It is a legitimate feature request (build-time base-mismatch warning for stage-snaps) with a concrete failure scenario, but the repo shows no code implementing such a check (stage_snaps is only referenced in models/project.py and grammar.py), so it is not fixed and should be assessed by a maintainer rather than closed.
Impact:
45
Quick Win:
20.25
Staleness:
75
Complexity:
55
Confidence:
70
Support Request:
10
Issue body
### What needs to get done
c/p from https://forum.snapcraft.io/t/snapcraft-should-fail-or-warn-when-using-a-stage-snap-with-different-base/21228
>When using a stage snap that has a different base (i.e. building a base: core18 nodejs snap using node from the 10/stable track) there will not be access to the glibc from the core base snap and the snap fails to run with apparmor denials like below:
>```
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.507:539): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libdl-2.23.so" pid=
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.507:540): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/librt-2.23.so" pid=
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.507:541): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/usr/lib/x86_64-linux-gnu/libstdc++.so.6.
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.507:542): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libm-2.23.so" pid=4
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.507:543): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libgcc_s.so.1" pid=
>Nov 21 12:54:53 localhost audit[4123]: AVC apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libpthread-2.23.so" pid=4123 comm="node" requested_mas
>Nov 21 12:54:53 localhost audit[4123]: AVC apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libc-2.23.so" pid=4123 comm="node" requested_mask="r"
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.511:544): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libpthread-2.23.so"
>Nov 21 12:54:53 localhost kernel: audit: type=1400 audit(1605963293.511:545): apparmor="DENIED" operation="open" profile="snap.picviewer-kiosk.file-browser" name="/snap/core/10185/lib/x86_64-linux-gnu/libc-2.23.so" pid=4
>Nov 21 12:54:53 localhost kernel: node[4123]: segfault at 0 ip 0000000000000000 sp 00007ffda5de47a8 error 14 in node[3ff000+1000]
>```
>since snapcraft unpacks stage snaps, it can surely also check what base a stage snap uses, it should then fail the build or at least warn that you can not combine stage snaps with the chosen base.
I believe a warning is better suited than an error. It is possible that the contents inside of the staged snap are statically built or they could be a script and will run just fine on a different base.
### Why it needs to get done
This will help developers creating snaps be aware at build time why their snap may fail to work. It can also help catch issues at build time where a staged snap was upgraded to a new core but the base snap doing the import was not.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
45
Quick Win:
20.25
Staleness:
75
Complexity:
55
Confidence:
70
Support Request:
10
|
needs triage | Request to add a build-time warning when a snap stages another snap built on a different base, preventing runtime AppArmor denials. Open, unlabelled, no maintainer response; only an automated Jira sync comment. Inactive for ~18 months. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
85
Complexity:
20
Confidence:
80
Support Request:
10
|
needs triage | Request to add a build-time warning when staging a snap with a mismatched base, preventing runtime AppArmor denials and crashes. Currently unlabelled and inactive for over a year. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
85
Complexity:
35
Confidence:
90
Support Request:
10
|
needs triage | Feature request to warn or fail builds when staging a snap with a different base, preventing runtime AppArmor and library errors. Currently unlabelled and untriaged. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
78
Complexity:
35
Confidence:
60
Support Request:
10
|
needs triage | Warn builds when staging a snap with a mismatched base to prevent runtime AppArmor and library failures. Prefers a warning over a hard error. Currently open and awaiting implementation after internal Jira ticket creation. Inactive for 460 days. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.