so my Fedora installation was upgraded in place from 35 onward, survived three SSD upgrades (all glory to btrfs send | receive
), got switched to systemd-boot
, then from Gnome to Plasma, so there’s some junk hanging about.
one of those is my flatpak setup that’s system-wide, as was the style at the time, instead of the current user-level. although everything works, there are enough irritants (like forcing crappy electron apps to use wayland) that the old way is just a chore now. so, here’s my brief write-up on how I made the switch.
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo
/flathub.flatpakrepo
flatpak list --system --columns=application > system_flatpaks
edit the list by removing various org.kde., org.gtk., org.freedesktop., etc. runtimes and save it as e.g. flatpak_apps
. otherwise, the following install and remove processes will ask tons of questions as to versions and nobody got time for that; the unused runtimes will be autoremoved later.
flatpak install --user $(cat flatpak_apps)
after it’s done, time to pull the dependencies; no idea why they don’t get pulled in the first place, when installing? anyhoo:
flatpak --user upgrade
will pull everything that’s needed. thanks to the glory of btrfs deduping, this won’t take up any additional space as it’s already on the disk. to remove the system apps:
flatpak remove --system $(cat flatpak_apps)
after it’s done, the runtimes:
flatpak remove --system --unused
and finally list all the system repos and remove them:
flatpak remotes --system
flatpak remote-del --system {flathub,flathub-beta,fedora-testing}
all app data remains safe and untouched in ~/.var/app
, everything works as before and no reboots necessary. from this point forward, it’s not neccessary to include the --user
switch.
bonus content: if you haven’t set up flatpak autoupdate, fix that post-haste.
~/.config/systemd/user/flatpak-autoupdate.service
[Unit]
Description=Update user Flatpaks
[Service]
Type=oneshot
ExecStart=/usr/bin/flatpak update --assumeyes --noninteractive
[Install]
WantedBy=default.target
~/.config/systemd/user/flatpak-autoupdate.timer
[Unit]
Description=Update user Flatpaks daily
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
systemctl daemon-reload
systemctl --user enable --now flatpak-autoupdate.timer
Wait, if I run
flatpak list --system --columns=application
, it looks like all my Flatpaks are system Flatpaks. Runningflatpak list --user --columns=application
shoulds just a couple of platform packages. What am I missing out on? What is this needed for:(Either way, thanks for writing up a detailed guide!)
if you’ve installed flatpak recently, say F40 onward, it should default to user. if it’s an old install then your flatpaks are system-wide. there isn’t a downside for either case per se, but user being the default for the future prevents potential issues.
my issue is, when I need to edit a
.desktop
file (to include ozon flags and whatnot) for a system-wide flatpak app, plasma doesn’t edit the app’s.desktop
file but incorrectly inserts a symlink to the user-wide version (which doesnt exist). there are ways around that, like removing the symlink and manually copying the file from/var/lib/flatpak/wherever
to~/.local/share/applications/
and editing it there, but then plasma doesn’t pick up the change immediately so this works better for me.Ha OK, I don’t know what ozon is and I don’t think I’ve had to edit
.desktop
files so far, so I’m probably good. I’m on Silverblue, so I suppose they’re still doing system installs, or are looking at existing packages and following their lead.Thanks for the clarification!
they are switches for electron apps, as some of them default to run under X11. so for e.g. element, it should be
flatpak run im.riot.Riot --enable-features=UseOzonePlatform,WebRTCPipeWireCapturer --ozone-platform=wayland
.you can check if all your apps are using wayland by running
xlsclients
in terminal while you got them open; an empty response means all wayland.