System updater

███████╗██╗   ██╗███████╗████████╗███████╗███╗   ███╗
██╔════╝ ╚██╗██╔╝██╔════╝╚══██╔══╝██╔════╝████╗ ████║
███████╗  ╚███╔╝ ███████╗   ██║   █████╗  ██╔████╔██║
╚════██║   ██╔╝  ╚════██║   ██║   ██╔══╝  ██║╚██╔╝██║
███████║   ██║   ███████║   ██║   ███████╗██║ ╚═╝ ██║
╚══════╝   ╚═╝   ╚══════╝   ╚═╝   ╚══════╝╚═╝     ╚═╝

The dms system update command checks for pending updates and optionally upgrades your system using the package managers actually installed on the machine. It talks to APT, DNF / DNF5, Pacman, Paru, Yay, Zypper, rpm-ostree (Atomic / Silverblue-style deployments), and Flatpak — whichever combination is available — without going through the DMS compositor daemon for normal check and upgrade flows.

info

Listing and applying updates runs locally against those tools. You do not need dms running as a server for dms system update or dms system update --check. The optional --interval flag is the exception: it configures how often a running DMS server polls for updates.

What gets used

DMS picks one primary system backend (the first candidate that reports itself as available) plus overlay backends:

• System: one of APT, DNF5/DNF (skipped when rpm-ostree indicates an ostree-booted system so the transactional backend can take over), Pacman, Paru, Yay, Zypper, or rpm-ostree, depending on what is installed and what the environment reports.
• Overlays: Flatpak is included when the flatpak CLI is present.

On Arch-based systems, Paru or Yay is preferred when installed so both repository and AUR updates can be discovered and upgraded in one flow. Plain Pacman covers official repos only.

Updates from each backend are merged into a single list; upgrades run per backend in sequence, only for packages that belong to that backend.

Usage

dms system update --check              # list pending updates only
dms system update                      # list, then prompt; upgrade if you confirm
dms system update --noconfirm          # upgrade without a prompt (also -y)
dms system update --dry                # simulation only (no persistent changes)
dms system update --check --json       # machine-readable listing
dms system update --no-flatpak         # skip Flatpak overlay
dms system update --no-aur             # skip AUR targets when using Paru/Yay
dms system update --interval 3600      # set server poll interval to 3600 seconds (needs running server)

Flags

Flag	Effect
--check	Query package managers and print available updates; never installs upgrades.
--noconfirm / -y	Apply upgrades without an interactive confirmation prompt.
--dry	Run upgrade commands in a non-destructive / dry-run mode where supported.
--json	With --check, print JSON (backends, packages, count, error).
--no-flatpak	Omit Flatpak from both discovery and upgrades.
--no-aur	When using Paru or Yay, drop AUR-only packages from the plan (repo updates still apply).
--interval <seconds>	Call the running server’s sysupdate.setInterval RPC and exit; does not upgrade locally by itself.

Interactive vs scripted runs

If standard input is not a TTY (for example in CI or a pipe), DMS refuses to apply upgrades unless you pass --noconfirm or only --check. Use --check for inventory scripts and --noconfirm when you intend unattended upgrades.

Timeouts and privileges

• Checking for updates uses a short timeout (on the order of a few minutes) so a stuck package manager does not hang the CLI indefinitely.
• Applying upgrades uses a longer timeout (on the order of tens of minutes).
• When privilege escalation is required, DMS uses sudo, doas, or run0 — whichever it detects as appropriate — similar to other privileged dms operations.

Relationship to the DMS server

When the compositor-side server is running, it exposes IPC such as sysupdate.getState, sysupdate.refresh, sysupdate.upgrade, and sysupdate.setInterval so the shell UI can show update status and coordinate upgrades. The dms system update CLI is a separate entry point aimed at terminals and scripts; --interval is the bridge that adjusts the server’s polling schedule while it is online.