Flatpak: Remotes, Installation Scope & Application Lifecycle

A workstation can have dnf and Flatpak installed at the same time. They manage different inventories. dnf manages RPM packages in the operating system: a service, a command-line utility, or a library supplied by your distribution. Flatpak manages applications together with the runtimes those applications depend on. A runtime provides a defined set of libraries, and multiple applications can share it. Flatpak does not mean that every application carries a private copy of every library.

Think of two stockrooms with separate ledgers. An item recorded in the RPM ledger does not automatically appear in Flatpak's ledger. Successfully installing an RPM proves that you can manage that RPM; it says nothing about whether you can configure a Flatpak remote or remove a Flatpak application. When troubleshooting, start by finding which inventory owns the application. Running dnf against the name of a Flatpak application will not manage that Flatpak installation.

Scope is part of the task, not a cosmetic flag. A system-wide installation is available to users of the machine. A per-user installation belongs to the user running the command. The normal system location is /var/lib/flatpak; the normal per-user location is $HOME/.local/share/flatpak. The latter follows the user's data directory configuration, so do not hard-code another person's home directory. Applications, runtimes, and remote configuration belong to the selected installation.

Use explicit --system or --user flags while learning. If the request says to configure software for everyone, adding a remote only for your own user leaves the task unfinished. Equally, using sudo with --user can change whose user installation you are managing: root is also a user with a home directory. For a per-user exercise, run as the intended ordinary user. Additional named system installations exist, but these exercises use only the default system installation and your own user installation.

A Flatpak software source is called a remote. Its short name is a local identifier that you choose; its location determines which repository it actually uses. Calling a remote approved does not make it trustworthy. Obtain the repository location and signing information from a source you trust. A .flatpakrepo file describes a repository and can supply its verification key. Treat it as configuration you are choosing to trust, just as you would inspect an RPM repository's origin.

The optional VM example below uses Flathub's published repository description. It configures your own user installation and does not install an application. Read the operation's result and then inspect the state. The --if-not-exists flag makes repeated setup convenient, but it does not repair a remote that already has the same name and a wrong location. That is why verification must compare both name and URL, not merely search for a familiar name.

Adding remotes is only half of the job. Handovers and mirror moves leave remotes that already exist with the wrong location, or that should no longer be used. Three commands change an existing remote in the installation you name. remote-modify --url= points an existing name at a new location without deleting it. remote-modify --disable and --enable switch a remote off and on while keeping its configuration. remote-delete removes the configuration entirely. Deleting and re-adding a remote is also a valid repair, provided you add it back in the same scope with the right URL.

A disabled remote is easy to miss. Plain flatpak remotes hides it, so it looks gone even though it is still configured. Add --show-disabled when you audit, and read the Options column: a disabled remote shows disabled there. "Remove the retired remote" means it is absent even with --show-disabled; disabling it does not meet that requirement.

Flatpak application IDs commonly look like reversed domain names followed by an application name. Use the ID published by the application or repository rather than guessing from a desktop label. A reference can also identify architecture and branch. When more than one match exists, read the choices before confirming; the branch you select is part of what will be installed.

The example installs GNOME Calculator from the user remote configured above. The installer may also need a runtime. Review the application, runtime, permissions, and download size shown in the plan before accepting it. A first installation can require a substantial download even when the application itself is small. Avoid -y while learning so you can see those decisions. After installation, use the same scope to inspect the application inventory. A successful download alone is weaker evidence than seeing the expected application installed in the required location.

Uninstalling an application and deleting its personal data are different decisions. Removing the app normally preserves its data under ~/.var/app, allowing a later reinstall to recover settings. If the requirement is to remove an app while preserving user work, ordinary uninstall is appropriate. If the requirement explicitly includes erasing application data, understand that deletion before choosing --delete-data; it is not a harmless cleanup flag.

Runtimes are a third inventory. Removing one application does not mean every runtime it used is now unnecessary: another application may depend on the same runtime. flatpak uninstall --user --unused asks Flatpak to identify unused references in that installation. Read its proposal instead of deleting runtime directories manually. Removing a remote is different again: it changes a software source, not the application's ordinary uninstall lifecycle. Decide which state the task asks you to change, then inspect that state.

Work as an ordinary user on a disposable VM that has Flatpak and internet access. First record both the system and user remote lists. Configure the example remote in your user installation, inspect its URL, install the example application after reviewing its plan, and confirm its ID in the user application list. Check the system list separately: your per-user operation should not have installed a second copy there. Finally uninstall the user copy and verify that it disappears from that list.

For a second pass, explain each verification before you run it. Which installation are you inspecting? Are you checking a repository, an application, a runtime, or personal data? What result would prove the requested state, and what result would only look similar? If an operation fails, stop at that step and investigate its message; do not treat later commands as proof that an earlier operation succeeded. This exercise is self-directed practice, not a Signal9 machine-graded completion or an exam-readiness score.

For further study, consult the Flatpak user guide and command reference, comparing their options with your installed version's help. Red Hat's EX200 objectives separately list Flatpak repository configuration and package installation/removal. This lesson teaches both, while their hands-on coverage remains separate from RPM/dnf labs.

For graded remote practice, open [Repair an Offline Mirror Handover](/lab?id=rhcsa-flatpak-remote) and read its handover brief. It deliberately gives the system remote the wrong URL. Compare both scopes before making changes; then repair the system URL, configure the personal mirror for the current user, and remove only the retired system remote. Inspect the final name, URL and enabled state in each scope before grading. These mirrors contain no applications, so an empty remote-ls result is expected. Remote configuration completion does not count as application installation/removal proficiency.