Provide official AppImage builds

[probonopd]

Please provide official AppImage builds of HexChat in addition to Snap and Flatpak. An AppImage is a self-standing universal portable application bundle for Linux.

Some of the advantages of AppImage:

• Runs on most systems, not just those that come with Snap or Flatpak enabled
• Users can download AppImage directly e.g., from GitHub Releases, and hence know where it is coming from
• No root needed
• Simple: One app = one file
• Can use the existing Travis CI build system that is already in place

[TingPing]

No root needed

Flatpak does not require root.

Users can download AppImage directly e.g., from GitHub Releases, and hence know where it is coming from

I could start hosting a flatpakref file for releases also.

Anyway, I'll have to play with AppImage a bit and see if I feel like maintaining yet another option. The fact it is a single file isn't really valuable to me and I believe it takes a lot more work to make it actually portable and we lose all of the security benefits that the others provide.

[TingPing]

No root needed

Flatpak does not require root.

Users can download AppImage directly e.g., from GitHub Releases, and hence know where it is coming from

I could start hosting a flatpakref file for releases also.

Anyway, I'll have to play with AppImage a bit and see if I feel like maintaining yet another option. The fact it is a single file isn't really valuable to me and I believe it takes a lot more work to make it actually portable and we lose all of the security benefits that the others provide.

[probonopd]

@TingPing what do you mean by "I believe it takes a lot more work to make it actually portable"?

So far I have tested it successfully on
The resulting AppImage is known to run on

• CentOS-7-x86_64-LiveGNOME-1511.iso
• debian-live-8.4.0-amd64-gnome-desktop.iso
• elementaryos-0.4-stable-amd64.20160921.iso
• Fedora-Workstation-Live-x86_64-24-1.2.iso
• openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso
• ubuntu-14.04.1-desktop-amd64.iso
• xubuntu-16.04.1-desktop-amd64.iso

Let me know which others you are concerned about, so I can test there, too.

[probonopd]

@TingPing what do you mean by "I believe it takes a lot more work to make it actually portable"?

So far I have tested it successfully on
The resulting AppImage is known to run on

• CentOS-7-x86_64-LiveGNOME-1511.iso
• debian-live-8.4.0-amd64-gnome-desktop.iso
• elementaryos-0.4-stable-amd64.20160921.iso
• Fedora-Workstation-Live-x86_64-24-1.2.iso
• openSUSE-Tumbleweed-GNOME-Live-x86_64-Snapshot20160921-Media.iso
• ubuntu-14.04.1-desktop-amd64.iso
• xubuntu-16.04.1-desktop-amd64.iso

Let me know which others you are concerned about, so I can test there, too.

[TingPing]

@TingPing what do you mean by "I believe it takes a lot more work to make it actually portable"?

You currently just throw some binaries in a file and hope it runs, it doesn't actually make a portable environment. Even looking at this is some sort of joke:

https://github.com/probonopd/AppImages/blob/master/excludelist

Just for example libgobject-2.0.so.0 is included in there, so instantly that means you must have very specific [ABI compatible] versions of gobject that we link to. I admit in practice many distros have this sure, but that doesn't mean its truely portable.

With Flatpak we pull in 0 libraries from the host. Yes it does require Flatpak installed on host but beyond that point it can run anywhere. Not only does that make it more portable it makes it an actually reproducible environment that we can reasonably test and support.

Also with Flatpak it exports the desktop file, appstream data, and icons so it integrates with the desktop like a normal application.

I fail to see a real benefit this provides. It feels like a hack that sort of works on common distros.

[TingPing]

@TingPing what do you mean by "I believe it takes a lot more work to make it actually portable"?

You currently just throw some binaries in a file and hope it runs, it doesn't actually make a portable environment. Even looking at this is some sort of joke:

https://github.com/probonopd/AppImages/blob/master/excludelist

Just for example libgobject-2.0.so.0 is included in there, so instantly that means you must have very specific [ABI compatible] versions of gobject that we link to. I admit in practice many distros have this sure, but that doesn't mean its truely portable.

With Flatpak we pull in 0 libraries from the host. Yes it does require Flatpak installed on host but beyond that point it can run anywhere. Not only does that make it more portable it makes it an actually reproducible environment that we can reasonably test and support.

Also with Flatpak it exports the desktop file, appstream data, and icons so it integrates with the desktop like a normal application.

I fail to see a real benefit this provides. It feels like a hack that sort of works on common distros.

[probonopd]

@TingPing let's not open a general AppImage vs. Flatpak discussion here which may exceed the scope of this ticket. The use cases are different:

• User Joe wants to run HexChat on the latest Fedora installed on her hard drive. He may choose to use Flatpak
• User Jane wants to run HexChat on a CentOS 7 Live USB stick in the Internet Café. She may choose to use AppImage, since Flatpak does not run in this environment. She goes to the HexChat download page, downloads one file, makes it executable, done.

In a recent episode of the German podcast RadioTux Magazin November 2016
the differences were summarized around 22:00:

AppImage: Relatively simple - click, runs.

Snap: You have to install something, you have to login somehow to Ubuntu One, but then you can install something, runs.

Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.

So to say, ordered according to difficulty.

AppImage intentionally pulls in those libraries from the host that can reasonably be expected to be part of every target system in a recent enough version (such as not to be called "bloatware"). It works surprisingly well in practice, and has been for the past decade for me.

[probonopd]

@TingPing let's not open a general AppImage vs. Flatpak discussion here which may exceed the scope of this ticket. The use cases are different:

• User Joe wants to run HexChat on the latest Fedora installed on her hard drive. He may choose to use Flatpak
• User Jane wants to run HexChat on a CentOS 7 Live USB stick in the Internet Café. She may choose to use AppImage, since Flatpak does not run in this environment. She goes to the HexChat download page, downloads one file, makes it executable, done.

In a recent episode of the German podcast RadioTux Magazin November 2016
the differences were summarized around 22:00:

AppImage: Relatively simple - click, runs.

Snap: You have to install something, you have to login somehow to Ubuntu One, but then you can install something, runs.

Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.

So to say, ordered according to difficulty.

AppImage intentionally pulls in those libraries from the host that can reasonably be expected to be part of every target system in a recent enough version (such as not to be called "bloatware"). It works surprisingly well in practice, and has been for the past decade for me.

[TingPing]

Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.

It takes either having gnome-software installed and a single click or a maximum of 3 flatpak commands to 1 flatpak command depending on a few factors.

It is very easy to try to compare this to Flatpak as we are using that, it does as advertised, and I am comfortable supporting it.

Yes in the common case AppImage might work. They might not have to install anything. That doesn't mean we should support that when it is clearly a worse technical solution than the alternative.

[TingPing]

Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.

It takes either having gnome-software installed and a single click or a maximum of 3 flatpak commands to 1 flatpak command depending on a few factors.

It is very easy to try to compare this to Flatpak as we are using that, it does as advertised, and I am comfortable supporting it.

Yes in the common case AppImage might work. They might not have to install anything. That doesn't mean we should support that when it is clearly a worse technical solution than the alternative.

[TingPing]

Anyway I don't think there is any point in dragging out this discussion. I simply disagree with this concept:

AppImage intentionally pulls in those libraries from the host that can reasonably be expected to be part of every target system in a recent enough version (such as not to be called "bloatware").

And I don't think that there is anything to convince me otherwise. So instead of arguing I'll just close this and say that for my definition of portable I believe Flatpak to be a better solution which we already support.

[TingPing]

Anyway I don't think there is any point in dragging out this discussion. I simply disagree with this concept:

AppImage intentionally pulls in those libraries from the host that can reasonably be expected to be part of every target system in a recent enough version (such as not to be called "bloatware").

And I don't think that there is anything to convince me otherwise. So instead of arguing I'll just close this and say that for my definition of portable I believe Flatpak to be a better solution which we already support.