Tips and Tricks🔗
This page explains a few useful features of the Flatpak CLI.
Testing an app with a different runtime🔗
You can (for testing) run an application with a different runtime than it typically uses. For instance, to run stable gedit with the latest unstable gnome runtime you can do:
$ flatpak run --runtime-version=master org.gnome.gedit
You can also use a completely different runtime (but same version number):
$ flatpak run --runtime=org.gnome.Sdk org.gnome.gedit
If you just want to use the sdk instead of the platform like the above, a
better approach is to use -d
.
Warnung
Running against a runtime with a completely different ABI is undefined and unsupported behavior.
Downgrading🔗
It is possible to downgrade an installed application (or runtime) to an older build.
First you look for the commit you are interested in:
$ flatpak remote-info --log flathub org.gnome.Recipes
Then you deploy the commit:
$ sudo flatpak update \
--commit=ec07ad6c54e803d1428e5580426a41315e50a14376af033458e7a65bfb2b64f0 \
org.gnome.Recipes
Bemerkung
The example here uses sudo
for system installations because, unlike normal updates, downgrades are considered a privileged action. If the application is installed per-user you would run it as that user.
If you have Flatpak 1.5.0 or later, you can also prevent the app from being included in updates (either manual or automatic):
$ flatpak mask org.gnome.Recipes
Bisecting regressions in application builds🔗
In case the newest builds of an application introduce regressions, you can use
flatpak-bisect
to discover which commit introduced the regression. It works
just like git bisect
.
In case your distribution doesn’t install the flatpak-bisect
utility, you
can find it distributed alongside the Flatpak source code, in
https://github.com/flatpak/flatpak/blob/main/scripts/flatpak-bisect
First you update the application and get its history:
$ flatpak-bisect org.gnome.gedit start
Then, you should set the current commit as the first bad commit:
$ flatpak-bisect org.gnome.gedit bad
Now you need to find the hash of the first known good commit. For that, you can see the build history by running:
$ flatpak-bisect org.gnome.gedit log
To start bisecting, checkout the first known good commit you find:
$ flatpak-bisect org.gnome.gedit checkout 5cd2b0648618c9038fbc6830733817309ade29541cdd8383830bbb76f6accf0d
After setting the bad commit and the first known good commit, you can launch the application to verify if the current commit in the bisecting session is a good or a bad one.
To mark a commit as good or bad, run:
$ flatpak-bisect org.gnome.gedit good
Or:
$ flatpak-bisect org.gnome.gedit bad
flatpak-bisect
will inform you when the first bad commit is found.
Adding a custom installation🔗
By default Flatpak installs apps system-wide, and can also be made to install
per-user with the --user
option accepted by most commands. A third option
is to set up a custom installation, which could be stored on an external hard
drive.
First ensure that the config directory exists:
$ sudo mkdir -p /etc/flatpak/installations.d
Then open a file in that directory as root:
$ sudoedit /etc/flatpak/installations.d/extra.conf
And write something like this:
[Installation "extra"]
Path=/run/media/mwleeds/ext4_4tb/flatpak/
DisplayName=Extra Installation
StorageType=harddisk
See flatpak-installation(5)
for the full format specification. Replace the path with the actual path you
want to use. You can use df
to see mounted file systems and mkdir
to
create a flatpak
directory so the path specified by Path=
exists.
Then you can add a remote using a command like:
$ flatpak --installation=extra remote-add flathub https://flathub.org/repo/flathub.flatpakrepo
And install to it with:
$ flatpak --installation=extra install flathub org.inkscape.Inkscape
Bemerkung
If your custom installation is the only one with the remote you’re installing
from, --installation
can be omitted.
And run apps from it with:
$ flatpak --installation=extra run org.inkscape.Inkscape
Bemerkung
If your custom installation is the only one with the app you’re running,
--installation
can be omitted.
Configuring resource limits for apps🔗
When systemd is available, Flatpak tries to put app processes in a scope such
as app-flatpak-com.brave.Browser-*.scope
(in the case of Brave), with *
replaced by
an arbitrary suffix. This means you can create a file like
~/.config/systemd/user/app-flatpak-com.brave.Browser-.scope.d/memory.conf
with contents like:
[Scope]
MemoryHigh=1G
Then after a systemctl --user daemon-reload
, those
systemd.resource-control(5)
parameters will apply to all instances of that
app.