Lbry-desktop: Use AppImage for Linux builds

[zedeus]

AppImage allows you to make a single executable that can run on any Linux distribution with no setup or dependencies required. According to @filipnyquist electron-builder already has support for it, so the daemon just needs some changes.

[lyoshenka]

Please convince me that we want this, including downsides.

[filipnyquist]

• Works with most reasonably recent desktop Linux distributions. Well, almost.

• AppImageKit and its predecessor, klik, have been in the making for over a decade.

• AppImages can be downloaded and run without installation or the need for root rights.

• The key idea of the AppImage format is one app = one file. Every AppImage contains an app and all the files the app needs to run. In other words, each AppImage has no dependencies other than what is included in the targeted base operating system(s).

[probonopd]

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[lyoshenka]

What are the downsides to using AppImage?

[probonopd]

It is work to set it up and keep current. It is not integrated with the system's package management (which some consider a downside; others consider it a bug plus).

[tzarebczan]

With more users coming onboard, we need a universal installation method on Linux that will work across Distributions. If Appimage is intended to be that, we should pursue this further.

[tzarebczan]

@zestyr - we also had some discussion on flatpak here: https://github.com/lbryio/lbry-app/issues/570

Do you know which would be the better route to go in order to support the most Linux distros?

I see some comparisons here:
https://www.reddit.com/r/linux/comments/59njka/the_biggest_winner_of_snap_v_flatpak_is_appimage/
https://www.reddit.com/r/linux/comments/4kxbqp/appimage_snaps_flatpak_pros_and_cons_comparison/

[probonopd]

Unlike Flatpak packages and other solutions, AppImages run on most Linux systems out of the box, do not need root, and involve no complicated commands on the command line.

[kauffj]

Per discussion still happening on #570, it doesn't seem like there is a consensus regarding AppImage vs. Flatpak.

I'm open to changing this, but it's unlikely we're adding 2 new ways to package an app on our least popular OS.

[eriknelson]

Throwing my hat in; I'm a Fedora user that started playing around with lbry this weekend (exciting project!). Seeing only a .deb I had to build from source, which unfortunately requires setting up a bunch of deps, c libs, nvm, python virtualenv etc. I'm pretty used to having to do this, but I would have liked to have something like an AppImage if I'm just trying out the project.

I prefer Flatpak, but I'm mostly indifferent as long as there is a portable option. If you're evaluating runtimes, I would also consider snappy. They're pretty much the 3 competing solutions, with as far as I can tell, no clear front-runner.

[kauffj]

Thanks @eriknelson and glad you were able to still get this set up.

We'll look to get this fixed. Let me know if you'd be interested to contribute on this or elsewhere.

[probonopd]

This thread is about AppImage though.

Check out the AppImage support built into electron-builder. Should really make it easy to produce an AppImage.

[IGassmann]

Since we're using electron-builder which supports AppImage, I would recommend going for AppImage.

[tzarebczan]

Someone already built flatpak support, it think that bridges the gap we were missing (unless I'm mistaken).

https://flathub.org/repo/appstream/io.lbry.lbry-app.flatpakref

[kauffj]

As a Linux user, I have no strong opinions about packaging (the existing .deb works fine for me).

To me the best improvement to make here is a better upgrade process (most likely via apt, though possibly just via in-app upgrades). I'd lean towards whatever packaging makes this easiest, though if we can easily distribute both FlatPak and AppImage I'm fine with both.

[IGassmann]

This may be possible using the publish features of electron-builder. We could publish the app on Bintray which has access from apt if I'm not mistaken.

[lyoshenka]

@IGassmann have you looked at what Alex is doing in https://github.com/lbryio/lbry-app/issues/808? Will publish work well with auto-updates?. apt is ubuntu-specific, which is all we're targeting now, but if there's a good solution to install the app and keep it updated on other linux flavors, that would be great.

[IGassmann]

I'll look if it's feasible when https://github.com/lbryio/lbry-app/issues/808 will be merged.

[IGassmann]

New reasons for using AppImage:

• Add support to auto-update for Linux.
• Incorporate necessary dependencies inside the package.
• Supported by our building tool.

[probonopd]

An AppImage still seems not to be available from the GitHub Releases page.

[IGassmann]

@probonopd It'll be available for our next release which should appear next week.

[IGassmann]

After discussing the fact that you need to change the file permission to launch an AppImage package, it was decided to rollback our changes and not use AppImage. Our app will still be distributed as a .deb package for the time being.

That step is not intuitive and might result in an unpleasant experience for our users.

A possible solution for supporting non-deb distributions in the future will be to use snap builds.

[probonopd]

After discussing the fact that you need to change the file permission to launch an AppImage package, it was decided to rollback our changes and not use AppImage.

What?! This is a security feature of Unix-like systems, where an executable needs to have the execute permission in the filesystem.

It is really easy to do:

If you would like to get automatic desktop integration (and automatic setting of the execute permission for all AppImages), you can install the optional appimaged daemon.

Compared to setting the executable bit on an executable (something that is not specifically an AppImage thing but needed for __all__ executables), package mangers and similar systems are _much_ more complicated.

[kauffj]

@probonopd when I double click a .deb Ubuntu prompts me to install it. When I double click an AppImage _literally nothing happens_.

This is a clear _step backwards_ from a UX perspective, at least on any system with support for .deb based packaging.

Even more frankly, the fact that you can suggest that there are no UX issues around forcing users to right click and navigate complicated property menus every time they want to install a piece of software gives me doubt that you have proper mentality to understand how to build usable solutions.

I've read enough of of your other comments on threads that I don't expect to convince you that you are wrong about this, though I do hope you will take this as feedback to drop the dogma you have on this issue.

[kauffj]

@probonopd I've re-read that comment and feel it may have been overly aggressive. I'm leaving it as-is as an indication of the strength of feelings I have about this issue.

I do like the idea of AppImage a lot and I appreciate the work you are doing for the Linux and open-source community.

[probonopd]

@kauffj I agree that Linux desktops should do something useful (e.g., show a dialog) when a user double-clicks an executable (ELF) file that is missing the execute bit.

We have an issue for this:
https://github.com/AppImage/AppImageKit/issues/374

Unfortunately this is not limited to AppImages, and we can't solve this within AppImageKit. Only the desktop environments (GNOME, KDE,...) can fix this.

[kauffj]

@probonopd I did some minimal googling but could not find open tickets for the desktop environments. Given age of https://github.com/AppImage/AppImageKit/issues/374 I would guess these exist already? Could that issue be updated?

I'm happy to throw whatever minimal weight we have towards supporting this.

[probonopd]

I don't think anyone has opened them so far. Hence the statement,

If you care about this issue, then please open an issue ticket with your favorite desktop environment (...)

Thanks for your support on this topic.

[IGassmann]

@probonopd ticket submitted for KDE and Gnome.