This features:
- 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
10 Likes
@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 
2 Likes
Great job!
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:
- reporting available updates (easily achievable but pointless if the update utility don’t update)
- update utility support, it would just have to run
flatpak upgrade
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 
3 Likes
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 flatpak.
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.
Advantages:
- it is easier in general,
- qube has only software that I need in it, not all other apps (including proprietary) from template,
- it is more secure, because if something bad exists in flatpak-package it will only affect one qube, not all qubes which use some template,
- updates are easier, I just update one app, not even starting the template and not potentially affecting other qubes,
- everything is local and does not require to think about any Qubes OS specific tricks when part of the application is in another template.
- backup of such qube will have everything important to reuse it somewhere: both user settings and application in user’s directory.
Disadvantages:
The only one I see is higher disk size usage:
- applications cannot share flatpak dependencies across qubes,
- having multiple qubes with the same specific flatpak package will require space in each of them,
- backup size of such qube is also bigger.
2 Likes
Using flatpak --user in qubes is easy, that’s why I covered the template case which is a lot more complicated 
2 Likes
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
2 Likes
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. xl vcpu-list
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.
1 Like
The option in Qube Manager is Menu > View > Show internal qubes.
In 4.1, the update tool use salt with qubesctl.
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
fedora-38-min: OK
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 qubes-vm-update
[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.
https://github.com/QubesOS/qubes-desktop-linux-manager/pulls?q=%22qubes-vm-update%22
https://github.com/QubesOS/qubes-issues/projects/8#card-80654181
https://github.com/QubesOS/qubes-issues/issues/7443
Implement our own non-interactive update mechanism (not requiring DispVM in the middle)
edit:
for dom0, it still use Salt:
https://github.com/QubesOS/qubes-desktop-linux-manager/blob/main/qui/updater/progress_page.py#L161
for templates:
https://github.com/QubesOS/qubes-desktop-linux-manager/blob/main/qui/updater/progress_page.py#L223
2 Likes
Yes, exactly.
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 
2 Likes
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.
2 Likes