- Auto update with the template
- Using GNOME Software to install flatpak if you don’t want the command line
- Automatic Application menu syncing when adding/removing programs with flatpak
@marmarek if flatpak support is something you would like to see in templates, I explored the integration if you are interested.
It lacks plugins like dnf to run a command after changes, which is pretty dumb
Maybe we could also issue an enhancement request on qubes-issues? Therefore, the development and status updates would be clearly visible, as well as invitation for new ideas, e.g. if we want to integrate the process with the Qubes Update utility, so the packages get downloaded to a disposable and then securely passed to a template, among others.
Yes, I could filled an issue if there is none that currently exists.
A deeper integration would be nice, I could imagine:
However, the sync method is a bit hacky and I don’t know how it could be done better as flatpak doesn’t have support hook or plugins.
Why would you need to download in a disposable? rpm and deb packages are only downloaded through a proxy, not using a disposable AFAIK, only dom0 does that.
Flatpak packages aren’t single files like regular packages, installing a flatpak program requires downloading each of its files separately, which allows delta updates / revert , I have a local proxy using nginx for that, there are a TON of files in there
Thanks, quite interesting.
I also like flatpak, but I use it differently: mostly one qube per application.
To do that I installed
flatpak package in the template (
sudo dnf install flatpak).
And in qubes based on that basic template I add
--user flag to all calls of
E.g. to install some software inside the qube:
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak --user install remmina
flatpak --user run org.remmina.Remmina
Then I can make custom icon launcher on the panel to execute this software. No need to do anything with the template.
I can have qubes for apps, not templates for everything: whatsapp qube, telegram qube (maybe several is needed), any_specific_software_qube.
The only one I see is higher disk size usage:
flatpak --user in qubes is easy, that’s why I covered the template case which is a lot more complicated
I need to dive deeper into this topic, as I haven’t done so yet, but as of right now there’s literally a domain spawned on my computer named disp-mgmt-fedora-38 once I asked for updating my fedora-38 template.
I have the same the mgmt qubes start every time I update.
There also is an option in Qubes Manager to show the management qubes in the list.
I’m currently updating my fedora-38 and I don’t have this qube started. I think it’s only if you update dom0
For instance, you don’t need it to install a package in your template, while it will always appear if you install a package in dom0
We explored in the past a good integration with some failures due to: [ Feature ] Config file for flatpak env · Issue #2933 · flatpak/flatpak · GitHub
It’s only if you use the Qubes OS update tool, which is the recommended way to update template.
I just did, it didn’t spawn anything (on 4.2-RC3)
You don’t get any popup, but you can see the vms running with the xen utils, e.g.
You can probably also see them running in Qubes Manager if you enable the option to show them, they are hidden by default. I can’t remember the name of the option, but I think it’s the only one that is hidden by default.
The option in Qube Manager is
Menu > View > Show internal qubes.
In 4.1, the update tool use salt with
It use a disposable based on
default-mgmt-dvm to accomplish the update.
In 4.2, the new update tool use
qubes-vm-update which doesn’t require a disposable to update the template.
(tested on 4.2-rc3)
If you use the old method:
[user@dom0 ~]$ sudo qubesctl --skip-dom0 --targets=fedora-38-min state.sls update.qubes-vm
it indeed popup a new disposable to accomplish the update.
(you got the popup that the
disp-mgmt-xxx started and the disposable is visible in Qube Manager.
If you use the new tool
[user@dom0 ~]$ qubes-vm-update --targets fedora-38-min
fedora-38-min (no updates): 0%| | 0/100 [00:20<?, ?it/s]
it will not fire up any disposable.
Implement our own non-interactive update mechanism (not requiring DispVM in the middle)
dom0, it still use Salt:
Unless one uses flatpak a lot, having it inside a template is the worse approach imho.
Btw flatpak also allows for manual package downloads and can install these, which works nicely with Salt in Qubes OS.
this was it
Thanks so much for the write up! This is excellent and something I did not know how to do, but had wanted to explore.
@balko Even though it turns out that the usage for
flaptak --user is simple as @solene mentioned, I also appreciate you adding that here because I did not know how to do that or work with flatpak in qubes at all. When I don’t know something, it doesn’t feel simple because I am never certain if I will break something
How does the
flatpak --user method handle updates of the flatpak packages in the AppVM? Do you have to manually pull up a terminal in each AppVM and run
$ flatpak update
I am assuming that flatpaks wouldn’t update in the same way that @solene 's method does.
I had been using snap packages to install some packages in AppVMs, and the
qubes-snapd-helper seems to keep the snaps up-to-date when I run the GUI updater (R4.2).
I would prefer to use Flatpaks for individual apps in app-specific AppVMs, where possible. Keeping the Flatpack apps up-to-date seems challenging.
The updates are not connected to the template. My approach allows to use different versions of the same packages in different qubes.
The updates should be done with:
flatpak --user update inside the qube, not its template.
You can use a script from
dom0 to make updates in qubes automatic if you use one flatpak in so many qubes.
I use it differently, like one qube for WhatsApp, one qube for other application, like Telegram and etc. And in Telegram qube I have nothing from WhatsApp at all, so the security and privacy is increased with this approach compared to using some monstrous template with all apps.
This could also be done when the AppVm starts, so it’s always up to date.