You open GNOME Software and search for a familiar application
The results page shows two install buttons side by side. One pulls from Flathub. The other pulls from the official Fedora repositories. You want every future installation to default to one backend, but the settings menu offers no toggle. You are not missing a hidden preference. The behavior is intentional.
What is actually happening under the hood
GNOME Software does not manage packages directly. It acts as a unified storefront that queries multiple backends simultaneously. Under the hood, it talks to PackageKit for RPM packages and to the Flatpak daemon for sandboxed applications. When you search for an app, the storefront asks both services for matches. It then ranks the results based on metadata freshness, sandbox status, and your previous installation history. The interface shows whichever backend returns the highest score. There is no global switch because the two ecosystems solve different problems.
RPM packages integrate with the host system. They share libraries, follow the Fedora release cycle, and update alongside the kernel. Flatpak applications run in isolated containers. They bundle their own dependencies, update independently of the OS, and provide consistent behavior across distributions. Forcing a single default would break the design goal of showing the most appropriate backend for each workload. The storefront is designed to adapt, not to enforce.
The ranking algorithm also considers desktop file integration. RPM packages drop .desktop files into /usr/share/applications/. Flatpak applications place theirs inside the sandbox and expose them through the portal system. GNOME Software reads both locations and merges them into a single view. If you edit files in /usr/lib/ or /usr/share/, the package manager will overwrite them on the next update. Always place custom overrides in /etc/ or ~/.local/. The system preserves user modifications in those directories while keeping vendor files intact.
Trust the storefront's routing. Manual overrides create drift that breaks update cycles.
How to enforce your preferred backend
You can still enforce your preference by handling installations through the terminal. The command line gives you explicit control over which backend receives the package. Once the terminal installs the application, GNOME Software detects the active backend and routes all future updates through the correct service.
First, check whether both versions are currently installed. Conflicting installations waste disk space and cause update confusion.
flatpak list --app | grep -i <app-name> # Check for a sandboxed version
rpm -q <package-name> # Check for a system RPM version
If both exist, remove the one you do not want. The removal command depends on the backend you are discarding.
flatpak uninstall <app-id> # Remove the sandboxed version and its runtimes
sudo dnf remove <package-name> # Remove the RPM version and unused dependencies
Install your preferred version next. Use the exact identifier for the backend you want to keep.
flatpak install flathub <app-id> # Pull from Flathub with explicit remote
sudo dnf install <package-name> # Pull from Fedora repos with dependency resolution
GNOME Software will now recognize the active installation. Open the application page again. The interface will show the update button tied to the backend you just used. You do not need to configure anything else. The storefront reads the system state on launch and adjusts its routing automatically.
Run the terminal command first. Let the storefront catch up to your system state.
Verify the switch took effect
Confirm the active backend matches your intention. Run a quick status check to ensure the package manager and the storefront agree on the source.
flatpak info <app-id> # Shows installation location and active remote
rpm -qi <package-name> # Shows repository origin and install date
Open GNOME Software and navigate to the application page. The update button should reference the correct backend. If the interface still shows the old version, restart the storefront to clear its cache.
gnome-software --quit # Force a clean exit and drop cached metadata
gnome-software & # Restart with a fresh backend query
If the storefront still refuses to update, check the journal for backend communication errors. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu gnome-software muscle-memory style.
Restart the storefront before you debug. Half the time the mismatch is just stale cache.
Common pitfalls and what the error looks like
The most frequent issue is a stale cache in GNOME Software. The storefront caches search results to improve performance. If you switch backends via the terminal, the interface may still display the old install button until the cache expires or you restart the application. You will see the old backend listed even though the terminal shows the new one. Restarting GNOME Software resolves the mismatch immediately.
Another trap is leaving configuration files behind. RPM packages store user settings in ~/.config/ or ~/.local/share/. Flatpak applications isolate their configuration inside ~/.var/app/<app-id>/. Switching backends does not automatically migrate your preferences. You will need to copy the relevant configuration files manually if you want to preserve your setup. The terminal will not warn you about this during installation.
Dependency conflicts rarely occur between Flatpak and RPM versions because they live in separate namespaces. You will not see Error: Transaction test error: package conflicts with... when switching. The only conflict appears if you try to install two versions that claim the same desktop file ID without proper overrides. The terminal will refuse the second installation and print Error: Application <app-id> is already installed. Remove the existing version first.
Keep in mind that update commands differ between backends. You will run sudo dnf upgrade --refresh for system packages and flatpak update for sandboxed applications. They do not share a single update pipeline. Running both ensures your system stays current without mixing update channels. Fedora's release cadence is six months. The N-2 release goes end of life when N+1 ships. Plan your backend strategy around that cycle.
Check the actual error before guessing. The terminal tells you exactly which backend rejected the transaction.
When to use this approach versus alternatives
Use Flatpak when you want consistent application behavior across different Linux distributions. Use RPM when you need tight integration with system libraries and desktop services. Use the terminal to enforce your preference when GNOME Software shows an unwanted backend. Use GNOME Software for discovery and visual updates when you are comfortable with its automatic routing. Stay on the default storefront behavior if you only deviate from the defaults occasionally.
Trust the package manager. Manual file edits drift, snapshots stay.