Skip to main content
Version: 1.5

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 --ignore nvidia,docker # skip specific packages for this run
dms system update --interval 3600 # set server poll interval to 3600 seconds (needs running server)

Flags

FlagEffect
--checkQuery package managers and print available updates; never installs upgrades.
--noconfirm / -yApply upgrades without an interactive confirmation prompt.
--dryRun upgrade commands in a non-destructive / dry-run mode where supported.
--jsonWith --check, print JSON (backends, packages, count, error).
--no-flatpakOmit Flatpak from both discovery and upgrades.
--no-aurWhen using Paru or Yay, drop AUR-only packages from the plan (repo updates still apply).
--ignore <names>Skip specific packages by name (repeatable, or comma-separated). Excluded from both the listing and the upgrade.
--interval <seconds>Call the running server’s sysupdate.setInterval RPC and exit; does not upgrade locally by itself.

Ignoring packages

Use --ignore (or the Ignored packages list in the shell's System Updater settings) to keep specific packages pinned. Ignored packages are dropped from the update listing and excluded when upgrades run, using each backend's native mechanism so nothing is upgraded behind your back:

BackendHow the exclusion is applied
Pacman / Paru / Yay--ignore name1,name2 on the upgrade command
DNF / DNF5--exclude=name1,name2 on the upgrade command
APTThe packages are placed on a transient apt-mark hold for the duration of the upgrade and released afterward (holds you set yourself are left untouched)
ZypperA transient package lock (zypper al) is added for the upgrade and removed afterward (locks you set yourself are left untouched)
FlatpakOnly the remaining refs are passed to flatpak update explicitly

Package names entered in the shell settings are validated as letters, digits, and @._+:-. CLI values are passed as command arguments where possible; backends that require shell command construction discard unsafe names.

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.

sysupdate.upgrade accepts these optional params, mirroring the CLI flags:

ParamTypeEffect
includeFlatpakbool (default true)Include the Flatpak overlay in the upgrade.
includeAURbool (default true)Include AUR targets when using Paru/Yay.
ignoredstring arrayPackage names to skip; excluded from the plan and from each backend's upgrade command using its native mechanism (see Ignoring packages).
drybool (default false)Run a non-destructive dry run where supported.
terminalstringTerminal override for backends that upgrade interactively (AUR helpers).
customCommandstringRun a custom command in a terminal instead of the built-in upgrade flow.

When using the built-in updater, the shell populates ignored from the Ignored packages list in System Updater settings, so those packages are also skipped by Update All. Custom update commands control their own exclusions.