For this complete different approach (not Template based, no update warning, user not knowing if running latest version unless the app “phones home” and warns user of a newer version at runtime) this is a way to go.
Upstream software installation guides will sometimes only propose AppImages. Or snap/flatpak. In my own beliefs, AppImages are the last ones I would install, while I understand the need for packages maintainers wanting to deploy apps without burden of packaging those apps and maintaining repositories. Flatpak/snap on the other side depends on a repository-like system, but is working outside of Qubes update warning system: deploying applications from repositories will warn the user that updates are available. The use applying such updates will receive logs of what was updated. And tge user will receive warnings that qubes depending on an updated template needs to be restarted to run updated software. Flatpak/snap/Appimages won’t do that. Leaving the advanced user responsible to do the maintenance and keep track of what software was installed in which way and carefully maintain used softwares.
Micah Lee proposed an interesting app manager (which i hope has made its way into Qubes Contrib repositories @fepitre? ) which permits flatpak installation directly into a qube. But yet again, when a user launches that already installed app in a qube, said update scripts working in thr background will deploy the update without notification to the user to close and relaunch app.
I continue to be a firm believer that:
- Best way to deploy software is from repositories, if available.
- AppImages are last, since not updated automatically and requires from users a buch of additional steps to ensure of integrity/authenticity
- Snap/flatpak are better then nothing, where I try to push software maintainers to at least support debian/fedora. But Qubes support is not complete here, as said before. User will use older version until he restarts its qubes, after silent updates are applied, but where Micah Lee’s app manager improves the situation. Here, the user can decide to deploy flatpak in Template in a centralized way (where updates wont be installed automatically) or per qubes, which if app is usef in multiples qubes, network usage/disk usage goes up drastically, those payloads redownloading static dependencies to work on any linux, and where flatpak repositories are sometimes less frequently updated then their repositories counterparts and where packages maintainers are also sometimes not the from the software distribution team.
Convenience vs security, again
@adw thoughts here again welcome.