Our stance on and plans for Flatpak
I've been wondering what we should do with Flatpak. I'm personally a fan of the good ol' package manager, but I do see some benefits in using something like Flatpak. More so on mobile, where everyone is used to app-stores, than on desktop.
Some benefits I see:
- Sandboxing of apps
- Can act like an appstore using a front-end like Discover without developers needing to package their application for all phone distros out there
- Makes us using Musl less of a problem (I'm not entirely sure about this one)
Flatpak has already been packaged for Alpine Linux, so there is no extra work there. We could set up our own Flatpak repository rather than using Flathub (which has proprietary applications like Skype, Spotify, Steam, etc). In that case developers just have to submit their package to multiple repositories, rather than learning multiple package manager formats.
What do you guys think about this? Any huge benefits or disadvantages of supporting this? If we're going to use this, should we use it as our main application distribution platform, or just along-side the traditional package manager (we will still need the normal package manager for the base system of course)?
Activity
If we're going to use this, should we use it as our main application distribution platform
NEVER
"Sandboxing of apps" - This is nice on android, where most apps are pure evil, but on postmarketOS running of untrusted applications shouldn't be much of a concern.
"Can act like an appstore using a front-end like Discover without developers needing to package their application for all phone distros out there" - this cannot be reasonably solved right now when the adoption is so low for linuxy phone distributions, maybe ask Purism etc. what they have planned?
"Makes us using Musl less of a problem" - having Flatpak runtime as hard dependency kills the benefits of using musl imho
By Mis012 on 2018-12-13T15:17:24
-
I've asked Purism, they're going for Flatpak. To me it does seem logical to be honest, you don't want app developers to have to package for multiple distros separately, phones are just a different market than desktop. Anyways, I'm interested in your opinions.
By Bart Ribbers on 2018-12-13T18:01:38
-
There is this wonderful article by Kyle Keen: Maintainers Matter - The case against upstream packaging. It's a long read, but here are the subjectively three most important quotes that argue against giving app developers (he calls them "ISV") the possibility to directly submit their apps.
Apps shipping libraries
A distro can update a shared library once and all software is now safe, without needing to rebuild every piece of software using it. Most of the sandboxes do not share libraries and so you are waiting on the slowest ISV to rebuild their software. If they ever do. ISVs are notorious for using ancient libraries with extensive out-of-tree patches and never migrating the patches forward.
This is completely against the spirit of postmarketOS, isn't it? We're trying to unify all devices as much as possible, making them use ideally only one device specific package. If programs ship their own versions of shared libraries, then we have the forking problem all over again.
The two quotes below reflect my point of view as well, I have nothing to add to them.
Layer of quality control
Maintainers also shield users from developers, offering a layer of quality control. At the very least, all the software in a distribution should play friendly with any other piece of software in the repositories. Maintainers are responsible for that, as well as choosing a subset of the (subjectively) best software FOSS has to offer. Maintainers will disable features that they feel act in bad faith. Maintainers' greatest power is the ability to outright say "This is not good enough for our users" and consequently punish an ISV by either patching out the offensive part or in extreme cases removing the software from the repositories. ISVs know this and so don't act out. After 20 years of enforced good behavior this has lead to the idea of ISVs as "the benevolent upstream developer." This is why Linux doesn't have spyware, doesn't come with browser toolbars, doesn't bundle limited trials, doesn't nag you to purchase and doesn't pummel you with advertising.
Sandboxing doesn't make people ethical
App Stores have proven that ISVs will try to get away with as much abusive behavior as possible. Sandboxing protects against many threats, but does not suddenly make people ethical. Distributions with human maintainers are more likely to make mistakes than an OS-enforced sandbox, but human maintainers are also more likely to sniff out the dumb stunts that ISVs try to pull. No human maintainer is ever going to willingly package a flashlight app which phones home.
@Mis012 wrote:
"Sandboxing of apps" - This is nice on android, where most apps are pure evil, but on postmarketOS running of untrusted applications shouldn't be much of a concern.
IMHO we should do privilege separation (https://gitlab.com/postmarketOS/pmaports/issues/77), even for the regular applications installed by the package manager. We could possibly use bubblewrap, which Flatpak is using as well.
@PureTryOut wrote:
We could set up our own Flatpak repository rather than using Flathub (which has proprietary applications like Skype, Spotify, Steam, etc). In that case developers just have to submit their package to multiple repositories, rather than learning multiple package manager formats.
This improves the situation only slightly. As long as app developers are directly submitting their binaries, there's nobody from our (or Alpine's) side that can patch out the nasty things that they might do (examples from Chromium and Firefox come to mind).
Also, maintaining a flatpak repository in addition to our regular package repository is additional effort and complexity. I'd rather have one well oiled packaging machine, that makes it easy to contribute and maintain the packages. Some of that is present already with
pmbootstrap newapkbuild(and pmbootstrap in general, cross compiling packages is rather easy) and the CI that we have, which builds new packages automatically and has a few sanity checks on the packages. But I would like to extend it to automatically notify us of new upstream packages, and doing test-builds of them so it is minimal effort from our end to update the packages.@PureTryOut wrote:
Can act like an appstore using a front-end like Discover without developers needing to package their application for all phone distros out there
I'd like something that looks similar to an app store (e.g. F-Droid on Android), but installs packages from the package manager in the background.
Discover is based on PackageKit, which does not abstract Alpine's package format apk yet. We could either go into that direction. But I'm also playing with the idea of creating "postmarketos-app-$foo" packages, which install the program $foo - possibly directly from Alpine - and add a sandboxing/touch/postmarketOS-specific configuration and optimizations on top of it. Consider firefox and
mpdas such packages.By Oliver Smith on 2018-12-14T23:20:28
mentioned in issue postmarketos#18 (closed)
By Oliver Smith on 2020-03-08T13:27:20
mentioned in issue wiki#59 (closed)
By Alexander Brzoska on 2021-02-22T13:23:25