FlatPak support

[mikehearn]

Vote for this feature if you'd like to see support for FlatPak repositories on Linux.

NB: Please only vote for one new package format at a time, so we can get an idea of which ones matter most.

[Merrit]

I hope support for the Flathub store will be considered as well. :+1:

[mikehearn]

@Merrit Looks like it's accumulating votes so we may take a look soon. What's your goal with the Flathub store - is it getting updates/installs on non-Debian/Ubuntu distributions?

[Merrit]

@mikehearn Yes, I personally use Fedora on my machines and I get my software from either RPM repos or Flathub.

For my apps on Linux I've had the best luck so far publishing on Flathub since it gives discoverability in app stores with things like a description, screenshots, links, reviews, automatic updates, etc - not to mention that packaging this way means my app is now available to essentially all linux users regardless of distro.

[mikehearn]

Right - we have some half-finished RPM support already, that's why I was asking. It might be easier to ship that first. The problem with Flatpak is the mandatory sandboxing, it can break frameworks that weren't updated to use the portals APIs. I'd worry that if we offered it, people would find it just doesn't work. Perhaps this view is behind the times though. We'd also need to implement the ostree format (or, create OCI/container flatpaks). RPMs in contrast are relatively low risk and there's a JVM library that makes them already, we just have to use it and maybe expose some metadata via the config file.

[Merrit]

The problem with Flatpak is the mandatory sandboxing, it can break frameworks that weren't updated to use the portals APIs.

I think this is just part of shipping sandboxed apps, you do have to take into account some particularities when doing so. I do however appreciate striving to make things as straightforward as possible!

I am not sure how the auto-updates are handled (I only just discovered Hydraulic!).. at the moment downloading a random .rpm file to install is not something I would consider a good user experience, however if that rpm can then auto-update it might be a good alternative.

I'd wonder: would updating require user interaction? Entering the superuser password to install / update system packages is normal, but if every app packaged this way triggered a password prompt for update it could be rather annoying.. one of the benefits of Flathub is that updates are automatic and silent.

[mikehearn]

The way we do it with debs is that the deb drops a file into /etc/apt/sources.list.d so installing the deb also configures automatic updates. I guess the same is possible on Red Hat based distros. Updates are applied in the same way as normal. I think in Ubuntu at least you don't have to enter the password to apply updates, or at least, if you do then you do it once for all updates in a batch (don't quite recall). It's the system UI at any rate, we don't do any custom update UI on Linux.

Automatic background updates are pretty nice indeed. I wonder how much control the app has over them? E.g. on windows/macos we offer a feature called "aggressive updates" where the app forces an update check on every start, and any pending updates apply synchronously. So devs and users get a kind of almost web-like experience where the app is always fresh as long as it gets restarted from time to time, equivalent to the user closing and reopening a tab for a SPA. We don't currently offer that on Linux but in theory it'd be easy enough with system package managers: just run words to the effect of gsudo apt-get update && apt-get upgrade package-name if we detect the app is out of date. Perhaps Flatpak offers a portal to the same. Not a big deal if not either way, we can always just ask the user to force an update if the app finds itself to be stale.

[mikehearn]

Ah ha, there is indeed a portal API for that:

https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Flatpak.UpdateMonitor

So with flatpak we can implement aggressive updates, super duper.

[Merrit]

That's pretty neat! Notification of available update, request update, etc. Sounds like a very useful portal.

[Sage-Kreiter]

Any plans to work towards this in the near future?

[mikehearn]

Not in the near future unfortunately. The next feature priority is to expose manual updates and an update control API.

[ctadlock]

It seems like a lot of momentum is moving towards this.