Use AppImage for Linux builds

zedeus commented

2017-07-06 20:57:24 +02:00

(Migrated from github.com)

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.

[AppImage](http://appimage.org/) 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.

👍 5

lyoshenka commented

2017-07-06 23:16:14 +02:00

(Migrated from github.com)

Please convince me that we want this, including downsides.

filipnyquist commented

2017-07-07 15:43:32 +02:00

(Migrated from github.com)

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

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

2017-07-24 02:21:49 +02:00

(Migrated from github.com)

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.

Providing an [AppImage](http://appimage.org/) 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](http://discourse.appimage.org/t/how-to-make-an-appimage-executable/80), 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](https://github.com/probonopd/AppImageKit/wiki/AppImages) of projects that are already distributing upstream-provided, official AppImages.

lyoshenka commented

2017-07-24 18:39:23 +02:00

(Migrated from github.com)

What are the downsides to using AppImage?

probonopd commented

2017-07-24 21:22:53 +02:00

(Migrated from github.com)

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 commented

2017-08-02 21:36:19 +02:00

(Migrated from github.com)

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.

👍 5

tzarebczan commented

2017-09-18 17:44:06 +02:00

(Migrated from github.com)

@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/

@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 commented

2017-09-18 20:13:13 +02:00

(Migrated from github.com)

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 commented

2017-09-19 15:32:33 +02:00

(Migrated from github.com)

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.

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 commented

2017-09-19 16:16:05 +02:00

(Migrated from github.com)

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.

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](https://www.ubuntu.com/desktop/snappy). They're pretty much the 3 competing solutions, with as far as I can tell, no clear front-runner.

kauffj commented

2017-09-19 20:56:06 +02:00

(Migrated from github.com)

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.

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 commented

2017-09-21 17:03:22 +02:00

(Migrated from github.com)

This thread is about AppImage though.

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

This thread is about AppImage though. Check out the AppImage support built into [electron-builder](https://github.com/electron-userland/electron-builder). Should really make it easy to produce an AppImage.

IGassmann commented

2017-12-12 17:56:12 +01:00

(Migrated from github.com)

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

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

tzarebczan commented

2017-12-12 17:58:39 +01:00

(Migrated from github.com)

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

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 commented

2017-12-12 18:22:01 +01:00

(Migrated from github.com)

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.

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 commented

2017-12-12 18:42:23 +01:00

(Migrated from github.com)

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.

This may be possible using the [publish features of `electron-builder`](https://www.electron.build/configuration/publish). We could publish the app on Bintray which has access from `apt` if I'm not mistaken.

lyoshenka commented

2017-12-12 20:28:16 +01:00

(Migrated from github.com)

@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 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 commented

2017-12-12 20:32:25 +01:00

(Migrated from github.com)

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

IGassmann commented

2018-01-19 17:40:47 +01:00

(Migrated from github.com)

New reasons for using AppImage:

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

New reasons for using AppImage: - Add [support to auto-update](https://github.com/electron-userland/electron-builder/tree/master/packages/electron-updater) for Linux. - Incorporate necessary [dependencies inside the package](https://github.com/electron-userland/electron-builder/issues/1082). - Supported by our [building tool](https://www.electron.build/configuration/linux#LinuxConfiguration-target).

👍 1

probonopd commented

2018-03-08 18:52:37 +01:00

(Migrated from github.com)

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

IGassmann commented

2018-03-08 18:53:33 +01:00

(Migrated from github.com)

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

👍 1

IGassmann commented

2018-03-14 21:09:37 +01:00

(Migrated from github.com)

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.

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 commented

2018-03-17 12:59:17 +01:00

(Migrated from github.com)

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.

> 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: ![](https://discourse-cdn-sjc2.com/standard12/uploads/appimage/optimized/1X/a4889c5cb8711d6845b58135080787d2f370af35_1_500x500.gif) 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](https://github.com/AppImage/AppImageKit#appimaged-usage). 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 commented

2018-03-17 20:08:07 +01:00

(Migrated from github.com)

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

@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 commented

2018-03-17 20:15:33 +01:00

(Migrated from github.com)

@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 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 commented

2018-03-18 09:44:11 +01:00

(Migrated from github.com)

@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 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 commented

2018-03-20 22:20:34 +01:00

(Migrated from github.com)

@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 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 commented

2018-03-21 19:21:06 +01:00

(Migrated from github.com)

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.

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 commented

2018-03-21 20:48:29 +01:00

(Migrated from github.com)

@probonopd ticket submitted for KDE and Gnome.

👍 2

Rows
Columns

Use AppImage for Linux builds #332