# 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.