Poll: Should we implement AppImage for Linux builds?

[evertonfraga]

Users have reported numerous (1, 2, 3) dependency issues while using our .deb bundling format.

We can get rid of the .deb issues altogether by migrating to a self-contained app model that does not require installation. It also works with several distros, making available to Fedorians, Arch-ians and so on.

"Download an application, make it executable, and run! No need to install. No system libraries or system preferences are altered. Can also run in a sandbox like Firejail"
https://appimage.org

Please use reactions (👍 👎), comments are allowed.

Thank you!

[probonopd]

Should be rather easy as electron-builder can produce AppImages natively.

[evertonfraga]

Thanks for chiming in @probonopd. And congrats on the project :)

[thekevinb]

I'm OK with .appimage . It has worked easily for the other two programs that I use that come that way.

BTW, I'm on Ubuntu.

[3esmit]

We should verify if AppImage provide meets security requirements for blockchain applications (opensource + tamper proof).
If so I think is a great thing to be used because its a good pattern for linux distros using applications files packed together with required libraries - but this might increase the size of file (because libraries are packed with file) however reduces problem with bad dependencies (privously installed shared objects might be tampered or in wrong version?)

[ktecho]

I used the .deb. Worker perfectly for me in Ubuntu 18.04 (beta).

Disappointed to not find .deb in latest version.

[jlmargason]

I don't like this idea, are all the issues with 32bit systems? Are legacy system users really the most important demographic? Taking away this deb is going to annoy a lot more people than the few on 32bit legacy systems that can figure out how to manually install it anyway.

Maintain the .deb and maybe add a .rpm. I don't understand why you don't have an official PPA so that this can stay up to date with the rest of my system.

AppImage sounds bloaty, and bloaty isn't very sexy. Secure automatic updates with the native package manager would be very sexy..

How are we supposed to update now that we installed with the deb previously? You tease us with a .deb one release then just take it away.. :(

[probonopd]

AppImage sounds bloaty, and bloaty isn't very sexy.

Are you talking about verifyable facts here or are you just guessing blindly?

[jlmargason]

I didn't make any guesses, I just described what it sounded like. I really don't care if the package is twice as large but I want it to work with my native package manager. I don't think this is too much to ask from a serious software project.

[probonopd]

@jlmargason there are examples where the AppImage is actually smaller than a normal installation. Think of AppImage like what is known as a "portable application" on Windows or an .app inside a .dmg disk image on the Mac. A package manager is not really needed for AppImages, as there is no installation and the files are "managed" by drag-and-drop. The advantage is that you can use the same file across many distribution (without having to re-download the same software for each distribution), and the application stays a separate entity from the OS (is not "baked in") and hence easy to move, remove, copy, etc.

[jlmargason]

I understand how it works, I'm a Linux Engineer. The fact that there is no installation is the issue. I want the software be installed on my system and conform to the XDG standard.

Using AppImage is great for systems that the .deb packages won't work on, and I'm sure many other edge cases, but I don't think it should be the official delivery strategy for all Linux systems.