Add support for _daemon_ as a valid system-username in snapcraft.yaml
Metadata
Current evaluation
Snapcraft formerly rejected `_daemon_` as a system username; current validation accepts arbitrary usernames, resolving the reported parsing failure.
Suggested action: close resolved
Reason: The current Project model accepts system_usernames as dict[str, Any], and the generated schema uses additionalProperties: true, allowing `_daemon_`; commit ffb164b7a removed snapcraft_legacy and the exact legacy validation error. The failure reported against 7.5.3 therefore no longer applies to the current codebase.
Evaluated by: mr-cal-bot
Impact:
38
Quick Win:
31
Complexity:
15
Confidence:
90
Actionability:
95
Issue body
With the release of snapd 2.61, a system-username of `_daemon_` is now supported and preferred over `snap_daemon`.
https://github.com/snapcore/snapd/pull/13052
A value of `_daemon_` cannot currently be parsed in snapcraft (7.5.3.post117+git2d596621) without using `passthrough:`
For example, the following:
system-usernames:
_daemon_: shared
produces the following error:
Issues while validating snapcraft.yaml: The 'system-usernames' property does not match the required schema: '_daemon_' is not a valid system-username.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
38
Quick Win:
31
Complexity:
15
Confidence:
90
Actionability:
95
|
close resolved | Snapcraft formerly rejected `_daemon_` as a system username; current validation accepts arbitrary usernames, resolving the reported parsing failure. | |
| stealth/space-bunny-alpha |
Impact:
34
Quick Win:
25
Complexity:
18
Confidence:
89
Actionability:
91
|
needs triage | Snapcraft's schema rejects _daemon_, the system username preferred since snapd 2.61; passthrough works around it. A clear compatibility fix awaits maintainer triage. | |
| qwen3.6-35b-a3b-mtp-q6 |
Impact:
30
Quick Win:
26
Staleness:
95
Complexity:
15
Confidence:
50
Support Request:
0
|
needs triage | Validation schema in snapcraft doesn't accept _daemon_ as a valid system-username, requiring passthrough workaround. Issue is 3 years old with no maintainer response. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
15
Confidence:
90
Support Request:
5
|
needs triage | Request to add daemon as a valid system-username in snapcraft.yaml to match snapd 2.61+. Currently untriaged, no maintainer response, and inactive for over two years. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
15
Confidence:
85
Support Request:
5
|
close stale | Request to update snapcraft.yaml schema to recognize _daemon_ as a valid system-username. The issue remains unlabelled, has zero comments, and has been inactive for nearly three years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
90
Complexity:
15
Confidence:
85
Support Request:
5
|
needs triage | Snapcraft fails to validate _daemon_ as a system-username in snapcraft.yaml, introduced in snapd 2.61. Issue is unlabelled, has zero comments, and has been inactive for nearly three years. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
snapd#13052
(confidence 100%)
The report links the compatibility requirement to snapd 2.61's upstream acceptance of `_daemon_`.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1845267 please support system-usernames, new in snapd 2.41 | snapcraft (launchpad) | closed | System-username support was implemented, including both YAML forms and long-form snap.yaml output, by merged PR snapcore/snapcraft#2858 (commit bad4d2d69). |