Add Flatpak support

[mattdangerw]

This PR adds support for building a flatpak for atom. See the feature request issue #11837

First time contributing, so please let me know if there is anything else I should do to get this in ship shape. I did not see any tests for other packaging scripts (e.g. create-debian-package.js) so I did not add any here.

A broader conversation should probably happen around how the library dependencies for the app are included. The build script here will try to download an electron "base application" which contains things like gtk and libnotify which are needed by any electron app.

This base app can grow with new dependencies of the electron project and contain bug fixes specific to electron. It allows anyone shipping an electron flatpak to avoid library quirks on different linux distributions. It does need to be hosted somewhere though.

For now, the flatpak recipe for building the electron base app is here
https://github.com/endlessm/electron-flatpak-base-app
and my company endless computers is hosting a compiled version of the base app on s3 here
https://s3-us-west-2.amazonaws.com/electron-flatpak.endlessm.com/electron-base-app-master.flatpakref

If there is interest, it would be fantastic if atom/electron project could be the official home of the electron base app going forward. We'd be happy to transfer the github repository and help with setting up a place to host the compiled version of the electron base application. Please ping me to discuss further. I can open a follow up issue in the electron repository if that is best.

On a related note, have started work on some node tools for building electron flatpaks, and have a few other app ports in progress.

Building

Requires flatpak > 0.6.13 installed. Then just

./script/build --create-flatpak

Testing

Install the flatpak and run it with

flatpak install --user --bundle out/atom-x86_64.flatpak
flatpak run io.atom.Atom

[mattdangerw]

This is where the electron base app (library depedencies) is hosted for now

[mattdangerw]

When I first started this port I didn't need this. But looks like this is needed from a recent bump in atom-keymap.

From what I can tell this is a specific atom requirement and not a general electron requirement, so I'm just building it into the app directly.

[Ben3eeE]

xkbfile was added via atom/atom-keymap#152

[mightyiam]

I've only heard about flat pack in #2956 but I'm guessing that it is way better for me than what I'm currently doing in Ubuntu, with the manual download.
Thanks.

[bugaevc]

By distributing the library requirements as a base application and not a runtime we can still allow the freedesktop runtime to handle things like critical security updates. If multiple electron apps are built against the same version of the base app, the libraries will still be deduplicated on disk when installed on a user machine.

I understand the above, but doesn't it kind of go against the intended usage of runtimes -- and neglect the problems that that usage solves? We'd need to download the Electron framework for every Electron app we install (and for every update), and every app vendor would need to provide critical security updates for the Electron framework separetely.

OTOH, if Electron is made a runtime maintained by a central authority, ex. GitHub/atom.io, it'd possible for security updates in freedesktop runtime to be automatically built into a new version of Electron framework and automatically deployed, almost immediately -- I mean, this would only require a small script on GH's side.

[mattdangerw]

@bugaevc I guess the rational is the libraries distributed in the electron base app are much less likely to need security updates then the freedesktop runtime. The approach here was suggested by @alexlarsson (the lead developer of flatpak) over adding another runtime.

However, as you said if an official electron runtime was building continuously with proper hooks setup to watch
https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-base
and
https://cgit.freedesktop.org/xdg-app/freedesktop-sdk-images/
that might be enough to waylay any security concerns.

[alexlarsson]

Whether you want to create your own runtime or not is up to you, although the general approach is to avoid creating runtimes as far as possible, because that makes you responsible for a lot more than you might want (in terms of maintainance and security updates), and we want to keep the number of runtimes in wide use somewhat low. Also, having to track down a separate repository for a custom runtime is slightly more work on the install side compared to using a more widely used runtime.

One of the reasons I think that it makes sense to not ship electron in a runtime is that it seems to update pretty often (with new APIs and whatnot), and any such update in a runtime would affect all the electron app currently in use, which kinda goes against the idea that a flatpak app runs exactly the same code that you tested it against (sans security updates and pure bugfixes). Having electron bundled in the app makes it likely that the app keeps running, even if its not maintained well anymore and other electron apps are moving forward faster. Runtimes are supposed to have extremely well definel and static ABIs to avoid this sort of things.

[damieng]

Hi.

At this time we have no resources available to support additional distribution formats beyond the ones for Atom on Linux we currently maintain (deb and rpm).