Offer Flatpak as Linux installation option

[jokeyrhyme]

Ubuntu has "click" packages:

• https://developer.ubuntu.com/en/publish/packaging-click-apps/

For everyone else (including Ubuntu):

• http://flatpak.org/

LibreOffice is now available via Flatpak:

• https://whatofhow.wordpress.com/2016/06/01/libreoffice-5-2-beta-flatpak/

Although there are some caveats:

Flatpak-based apps are not yet able to reach out to other applications installed on the machine (like browsers) to e.g. open URLs through them. That means that e.g. clicking on a hyperlink in a LibreOffice Writer document might not work yet.

Besides being a path to having a single Linux bundle format, there are also sandbox features that might be appealing. Might be nice to know that a VSCode extension can't modify /boot, etc.

[Tyriar]

Apparently click packages is the old name for snappy packages which is captured here #5458

The caveats sounds like an issue, xdg-open which is used by Electron to open URLs is an example of something that may break.

[jokeyrhyme]

It's entirely possible that it's just simply too early to jump on the click / Flatpak bandwagons. Fair enough.

I do think we'll see these evolve to have similar inter-app communication APIs that Android, WinRT and possibly iOS offers for their sandboxed apps.

Maybe in a fanciful future Linux utopia, we could have Flatpak and click instead of RPMs and DEBs, and have a far more comprehensive coverage of compatible distributions? :P

[jokeyrhyme]

http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

[jokeyrhyme]

flatpak/flatpak#116

[zaxebo1]

for me the biggest advantage of flatpak format is that I can install flatpak packages by using non-admin privileges.
whereas rpm/deb packages always need admin privilege for installation

[aperezdc]

Hi there! I am working on this at the moment and I have integration with the Gulp-based build system working in this branch. I still have to iron out a couple of details, but hopefully I'll be able to send a PR in the next days. Stay tuned!

[Tyriar]

Nice @aperezdc! After a quick look at the branch my main comment so far is that the task should go in gulpfile.vscode.linux.js

[aperezdc]

@Tyriar Wow, that was some quick feedback! I was doubting whether to add in gulpfile.vscode.linux.js or not myself... I'll take you advice and move the Flatpak bits in there before posting the PR. Thanks!

[Tyriar]

Cool, looking forward to it!

[aperezdc]

...aaand there goes the PR! I have added in a few more commits with some niceties:

• Optional support for writing output to an OSTree repository by defining the $FLATPAK_REPO environment variable (if given, it should be a local path). This is useful for distributing the Flatpak from a repository and being able to easily push updates to users.
• Optional support for signing builds with GnuPG by setting the $GPG_KEY_ID environment variable.
• An AppData XML data file, added also to the .deb and .rpm packages, which is used by some application managers (like GNOME Software) to display information about the application.

Also, I have tested locally that all the combinations of options generate working Flatpaks (repo vs. file, signed vs. unsigned, etc). I couldn't test the ARM builds, though.

[zaxebo1]

@aperezdc : May God bless you infinite times , for this PR

[Tyriar]

The PR has been merged so you should now be able to build flatpak in OSS builds. This issue will remain open for now until we choose to distribute flatpak.

[moosingin3space]

Does this help at all?

I like this idea a lot, it handles updating very nicely.

[jokeyrhyme]

Looks like Flatpak is currently the better cross-distribution bet: https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/

[directhex]

Don't want to speak for @Tyriar here, but I expect flatpak/flatpak#649 is a blocker.

[Tyriar]

@directhex 👍 , we will likely pursue snap packages first though.

[robinst]

Looks like the nice people of flathub are adding VS Code 🎉: flathub/flathub#150

[nedrichards]

@robinst that's just an 'extra-data' package sadly (but does get the 'official' branding because of that). I'd love to refresh the upstream support for flatpak which seems to have bitrotted a bit, especially to support network free builds with tools like recent npm or yarn, but just don't really have the time or expertise.

[amtlib-dot-dll]

@nedrichards Sorry but could you explain the word "bitrotted"? It doesn't seem to be an English word, thanks very much 😕

[jokeyrhyme]

@amtlib-dot-dll : "bit rot"": https://en.wikipedia.org/wiki/Software_rot :)

[AdrianKoshka]

I'd appreciate flatpak support, in Fedora Atomic workstation it's more encouraged to use flatpaks than traditional rpms.

[kt215]

I installed vscode flatpak on Linux Mint 19 (Cinnamon, Ubuntu 18.04), but vscode was unusable due to some access restrictions. The integrated terminal could not even see the installed dotnet sdk. I uninstalled and re-installed using the deb package instead, and that fixed the access/permission issue.

[Tyriar]

Looks like this is mostly handled by flathub, we don't really recommend using it officially though due to issues like @kt215 is suggesting.

[nedrichards]

Sure - from a flathub perspective we'd be happy to have interested parties working upstream at VS Code (and dependencies) to improve the way it operates inside a container or helping at flathub to keep it up to date, but there's no expectation of extra work being done, the world is busy enough.