Snaps, Flatpak and Other Software Formats

A host can have multiple software inventories. A program named firefox or editor may be provided by a Debian package, a Snap, a Flatpak, or a file installed by an administrator. Updating only APT does not update every one of them.

Identify the owner and update path

APT and dpkg manage Debian packages and their dependencies. Snap packages are managed by snapd, with revisions, channels, interfaces and a separate refresh mechanism. Flatpak applications and shared runtimes are managed per system or per user through configured remotes. Standalone binaries, language-specific environments and container images have still other owners and update paths. A container image is not a replacement for updating the host kernel or runtime.

Start by identifying a particular command instead of guessing its format:

type -a firefox
command -v firefox
readlink -f "$(command -v firefox)"

If the command is missing, command -v returns nonzero and there is no resolved path to inspect. A launcher or wrapper may hand off to another manager; a Debian-owned launcher does not prove the application payload is a Debian package. Follow the actual execution path and compare inventories:

dpkg-query -S /usr/bin/firefox
snap list
flatpak list

The example path may be absent or unowned; the snap or flatpak commands may not be installed. Run the relevant query only when its manager exists, and inspect the path actually found. Manager inventory and application behavior both matter.

Snap: revisions, confinement and refresh

Where snapd is installed, inspect without installing or changing anything:

snap list --all
snap refresh --time
snap changes

A Snap has a publisher, channel and revision; snap list --all may show retained disabled revisions. Snaps normally refresh automatically. Strict confinement uses interfaces to mediate access, whereas classic confinement grants broader host access; confinement is not a guarantee that an application is safe. A refresh can affect running services or application sessions. Snap’s update documentation explains schedules, holds and their scope.

A targeted refresh can bypass a hold on that specific snap; do not treat a hold as an immutable freeze. Reverting to a retained revision can restore some revision-specific data, but common application data and external databases can remain changed. Test the application’s own recovery procedure and compatibility before relying on a revert. See Snap revisions for data behavior.

Flatpak: applications, runtimes and remotes

If Flatpak is installed, inventory both applications and runtimes, and distinguish the user and system installations:

flatpak remotes --show-details
flatpak list --app
flatpak list --runtime

A remote is a software source with its own trust and lifecycle. An application can depend on a runtime maintained separately from the host’s Debian libraries. Permissions and desktop portals mediate access, but available grants and overrides change the effective boundary. Inspect an installed application’s declared permissions with flatpak info --show-permissions APP_ID; use an actual application ID from the inventory. See Flatpak’s concepts and command reference.

No installation or permission change is required for this exercise. On a server, avoid installing an additional manager simply to run these queries. Missing tools and empty lists are legitimate inventory results.

Make one maintenance inventory

For each application record its executable or launch method, manager, publisher/source, version or revision, automatic update policy, data location, privileges, restart needs and removal/restore method. Do not assume apt remove removes a Snap or that removing an application removes its data. A script in /usr/local, a language virtual environment or a vendor tarball may have no central update service at all; assign an owner and patch process explicitly.

Worked diagnosis and practice

A desktop application is reported vulnerable after apt upgrade succeeds. Determine which application is actually launched, inspect its manager and source, and compare its installed revision against the publisher’s advisory. Check whether a pending refresh requires the application to exit. Update using that manager’s documented process in a maintenance window, then verify the running application. On the lab clone, create a two-column inventory of installed managers and sources; explain what each manager does not update.