New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer Flatpak as Linux installation option #7112

Closed
jokeyrhyme opened this Issue Jun 2, 2016 · 24 comments

Comments

Projects
None yet
@jokeyrhyme
Copy link

jokeyrhyme commented Jun 2, 2016

Ubuntu has "click" packages:

For everyone else (including Ubuntu):

LibreOffice is now available via 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

This comment has been minimized.

Copy link
Member

Tyriar commented Jun 2, 2016

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.

@Tyriar Tyriar self-assigned this Jun 2, 2016

@Tyriar Tyriar changed the title [FEATURE REQUEST] offer Flatpak / click as Linux installation option Offer Flatpak as Linux installation option Jun 2, 2016

@jokeyrhyme

This comment has been minimized.

Copy link
Author

jokeyrhyme commented Jun 2, 2016

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

This comment has been minimized.

Copy link
Author

jokeyrhyme commented Jun 15, 2016

@zaxebo1

This comment has been minimized.

Copy link

zaxebo1 commented Sep 20, 2016

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

This comment has been minimized.

Copy link
Contributor

aperezdc commented Nov 25, 2016

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

This comment has been minimized.

Copy link
Member

Tyriar commented Nov 25, 2016

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

This comment has been minimized.

Copy link
Contributor

aperezdc commented Nov 26, 2016

@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

This comment has been minimized.

Copy link
Member

Tyriar commented Nov 26, 2016

Cool, looking forward to it!

@aperezdc

This comment has been minimized.

Copy link
Contributor

aperezdc commented Nov 28, 2016

...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

This comment has been minimized.

Copy link

zaxebo1 commented Nov 30, 2016

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

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Dec 14, 2016

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

This comment has been minimized.

Copy link

moosingin3space commented Feb 6, 2017

Does this help at all?

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

@jokeyrhyme

This comment has been minimized.

Copy link
Author

jokeyrhyme commented Feb 10, 2017

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

@directhex

This comment has been minimized.

Copy link
Member

directhex commented Oct 30, 2017

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

@Tyriar

This comment has been minimized.

Copy link
Member

Tyriar commented Oct 30, 2017

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

@robinst

This comment has been minimized.

Copy link

robinst commented Nov 14, 2017

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

@nedrichards

This comment has been minimized.

Copy link

nedrichards commented Nov 16, 2017

@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

This comment has been minimized.

Copy link
Contributor

amtlib-dot-dll commented Nov 17, 2017

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

@jokeyrhyme

This comment has been minimized.

Copy link
Author

jokeyrhyme commented Nov 17, 2017

@AdrianKoshka

This comment has been minimized.

Copy link

AdrianKoshka commented Nov 20, 2017

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

@kt215

This comment has been minimized.

Copy link

kt215 commented Aug 22, 2018

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

This comment has been minimized.

Copy link
Member

Tyriar commented Sep 12, 2018

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

@Tyriar Tyriar closed this Sep 12, 2018

@nedrichards

This comment has been minimized.

Copy link

nedrichards commented Sep 13, 2018

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.

@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 27, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.