mesh-catalog/modules/snapd

snapd

Snaps on the two workstations (novox/hq research 027/02: "snapd and flatpak are modules, on the two workstations only"; to-be 42 phase 2 step 9).

Status: tools only, the package blocked

snapd is not in the distribution's official repositories. It is a user-repository (AUR) package: on the desktop it is installed as a foreign package, and pacman -Si snapd finds nothing. The host's package shape installs from the official repositories only, so this module cannot declare it.

Neither form of ADR 0205 fits either. snapd is a daemon in compiled code with setuid helpers, a socket, services and a system mount, so it is not a pinned archive of plain files. The way out is research 027 question 1, option P2: the build machine builds user-repository packages into a package repository the mesh serves. Until that exists:

• The module declares no resources. It does not even declare the units snapd brings (snapd.socket, snapd.apparmor.service). On a workstation without the package, the laptop today, those units do not exist, and the host would fail the module there. A declaration that cannot hold on every machine the module is assigned to is not written.
• The tools are written and work wherever snapd is installed. Where it is not, every tool says that, rather than answering an empty list.

When the repository exists, the module gains, in one change:

1. the package snapd;
2. snapd.socket enabled and running;
3. snapd.apparmor.service enabled only if the kernel runs AppArmor (below);
4. its tests.

Improves (once it owns the package)

• The disabled revisions become visible. snapd keeps old revisions for rollback. On the desktop on 2026-10-04 that was 1.7 GB of snaps, of which about 0.7 GB were disabled revisions: the previous code, core18, core20 and snapd. snapd_disk_usage answers it.
• A unit that does nothing is named. On the desktop snapd.apparmor.service is enabled, but the kernel's security modules are capability,landlock,lockdown,yama,bpf. There is no AppArmor, so the profiles it would load are enforced by nothing, and strict snaps run unconfined. snapd_status says so. Turning AppArmor on is a kernel command-line change, which is the kernel module's, and is the operator's choice.

Tools

All answer JSON; (r) reads, (a) acts. Reads run as the operator account; acts go through sudo -n. Acts use --no-wait: snapd carries them out in the background, and the answer is snapd's change id, followed with snapd_changes. No act outlasts the 20 s a call has.

tool	what
snapd_status (r)	installed or not, version, the four units' enabled and active states, AppArmor in the kernel, /snap present, and findings
snapd_list (r)	every revision: version, revision, tracking, publisher, notes, disabled
snapd_info (r)	one snap: fields, commands, channels
snapd_updates (r)	what a refresh would change
snapd_disk_usage (r)	bytes per snap and revision, the disabled revisions' share, the total
snapd_services (r)	the services snaps provide
snapd_changes (r)	recent changes, or one change's tasks
snapd_install (a)	install, optionally from a channel and in classic confinement
snapd_remove (a)	remove, keeping a snapshot unless purge
snapd_refresh (a)	refresh one snap, or all

What changes when it is assigned

Nothing on disk, on either workstation: the module declares nothing.

• desktop: the tools answer for its snaps: code (classic), its bases, gtk-common-themes, gnome-3-28-1804, snapd.
• laptop: snapd is not installed, and every tool says so.

Leaves as found

Everything: the package, its units, /snap, the installed snaps and their data.