I thought about this too. I’m not exactly sure how the Qubes Updater is implemented, i.e. with respect to disp-mgmt-*. I would think that as long as Flatpak/AppImage/Snap supports separation of the download an install operations, it probably wouldn’t be hard to adapt the Qubes Updater to it. It already somehow supports two different package managers (apt and dnf) so adding a third shouldn’t be all that hard. I’ll have to read up on it some more.
Thanks for your input! That would probably work for me. I haven’t actually tried AppImage at all yet (inside or outside Qubes), so I’ll definitely give it a try. I thought about offline installation with Flatpak too, but it’s not exactly straightforward. It sounds like AppImage is better suited for this.
At the moment I wouldn’t really need them to be shared across VMs either. I just brought it up because it would be nice to have that option, but right now I can’t think of any package I would need in a lot of different VMs. The networking part is a bigger problem for me, as some of my VMs don’t have internet access.
A NetVM isn’t actually required for installing just Flatpak itself, is it? It’s only when you enable a repo or install packages that it needs to be online?
This got me thinking… I wonder if simply qvm-copying a user-mode installed Flatpak could actually work. If so, I could setup a dedicated AppVM with appropriate networking for installing and updating Flatpaks, and then have a script copy the packages into the more restricted AppVMs where they’ll be run. It wouldn’t be very pretty, but it would be safe and automated then.
I would hope they’re using signatures and everything like you’d expect from any package manager in this day and age. Then again, last time I checked Gentoo and several other distros were still downloading unsigned packages from random mirrors over insecure http, so I guess you can’t be too sure.