Bug 505100

Created attachment 181960 [details]
Proposed button for adding Flatpak install locations within Discover

According to a closed issue in Flatpak (https://github.com/flatpak/flatpak/issues/1224#issuecomment-348665064), it is possible to change the installation path of Flatpak applications, rather than using the default location (in /var/...). In some cases this can be useful, especially for devices which have a low amount of primary storage and need to install apps to external storage (such as the Steam Deck). Or in devices which are shared between family members which all have a different user and want to only install apps for themselves.
The problem is, the Discover GUI does not expose this functionality and the users are not given any indication that this is possible in the first place.

I propose implementing:
1. a way to add custom install paths from within Discover
2. a way to choose the install location on the application details screen in Discover.

I believe the 2nd point is already implemented, since on one of my systems I have the option of choosing "Flathub" and "Flathub (user)" (although I'm not sure how this happened, since I don't remember setting this up and none of my other systems have this option. I don't see the option of installing an application to the user directory on my other devices, nor an option to enroll into this behavior.).

According to "flatpak-installation" manual:
1) "flatpak can operate in system-wide or per-user mode. The system-wide data is located in $prefix/var/lib/flatpak/, and the per-user data is in $HOME/.local/share/flatpak/."

This sounds like there should always be a default of 2 options in Discover: a system-wide AND a user installation. Or at least a way to opt users into setting up a per-user installation.
Currently, users are defaulted to the system-wide install and never told they can opt into installing apps in the user directory or in other/custom locations.

2) "more system-wide installations can be defined via configuration files /etc/flatpak/installations.d/"

Since this is a package manager feature, it makes sense to implement a GUI for it within Discover. (In my opinion)

One of the approaches could be the following:
Add an "Install locations" button which opens a pop-up screen. In the pop-up window, the user can manage install locations and create new ones. After creating a new location, it would appear in the dropdown when the user clicks "Install" in Discover.

Another approach could be:
Add an "Install location" dropdown with the following 3 default options: "System", "User", "Create new"
The dropdown would decide where the app is installed, instead of the way it works currently (The "Install" button opens it's own select menu where you choose the destination and the repository)
However, this could become confusing. Some systems may have multiple flatpak repositories, and from what I can see the manually created install locations are made per-repository rather than applying to each repo. So, this solution isn't ideal since the dropdown would become too busy in any scenario which involves multiple flatpak repos.

What this feature request is trying to resolve:

I've used Flatpak for about 3 years now and I only recently learned that you can actually create and specify install locations through the CLI. Until now I just lived with the fact that flatpaks must be installed inside "/var/...".
A couple of Linux users I know have relied on using symlinks to "install" flatpaks to external drives or even the user directory, as they didn't like them being installed in /var/lib/flatpak/. But, it looks like they were doing a hacky workaround for a feature which was already supported by flatpak for almost a decade.
To me this seems like the feature itself is not exposed to users at all (if it's exposed somewhere, I'm not aware of it). This means that users either have to:
a) somehow find the 8-year old github comment describing how to do this through the cli
b) resort to using workarounds (symlinks)
c) use Appimages and have them in the preferred directory, when they might want to use Flatpaks instead