Imagemagick: [Package Request] Please provide Linux binary packages in AppImage format

[KurtPfeifle]

I noticed that ImageMagick has tagged 41 different releases of the 7.0.x variant in 2017 alone. That is almost weekly a new release.

It would very nice and extremely welcome for users who want to get their hands on the latest and greatest of ImageMagick, if you also could provide binaries in the AppImage format, and if you could configure the build process which you already have automated with Travis to spit out such a beast.

TL;DR

An AppImage has the following advantages:

1. Directly runs on all major Linux distribution.
2. Similar functionality as "PortableApps" on Windows.
3. Directly runs from any location (even USB thumbdrives).
4. You can run different versions of the same App side-by-side.
5. No need to "install".
6. An AppImage is a single file.

Technically, an AppImage is posing as a normal ELF binary to the outside world. Inside, the most part of it is a compressed AppDir (see also Wikipedia) containing the application alongside the required run-time libraries and resources in the shape of an ISO file system tree. A small piece of extra code inside the AppImage auto-mounts the AppDir on a mount point in /tmp/.

Then it executes the binary inside the AppImage.

So, an AppImage is a file, which the end user can directly start (well, after making it executable), from any location (even USB thumb drive), across many different distros, old and new.

Actually, AppImages aren't even "packages" in the same sense as other software packages. They don't need an "install" step, as one is used to for other software. They bundle everything that is required into that one single file, which makes the "package management" as easy as managing simple files.

The most basic principle of the AppImage format is: "1 file == 1 application". Contrary to what the first reading of their website may lead one to believe ("So this is for Desktop / GUI applications only?"), AppImages work very well for CLI tools too.
_{(I've successfully tested AppImages made from the ippsample software, provided by the ISTO Printer Working Group [PWG] for prototyping and testing IPP Everywhere [Internet Printing Protocol] software.)}.

The "1 file == 1 application" makes it very easy for users to make use of the software:

1. Download + save 1 file only.
2. Make it executable.
3. Run it (from whereever you stored it).

The "1 file == 1 application" makes it also very easy for developers to provide their software to their audience:

1. An AppImage runs on most Linux distribution without change.
2. Different versions of a software may be used side-by-side (important for testers / developers / reviewers / trainers).
3. Even officially un-released versions of the software can be easily made available to those who love to run (or have to test) the "bleeding edge".

It would be easy to integrate the automated build of an AppImage via Travis upon every single Git commit by you guys.

I'm pretty sure that @probonopd, the lead AppImage developer will help to setup an automatic workflow for ImageMagick if you are interested in exploring this idea (maybe even prepare a pull request that you only need to test + accept).
_{(After all, even Microsoft now builds AppImages for their PowerShell 6.0.0 Betas, capable to run on multiple Linux distributions.)}

Implementing this would help many users who want to EASILY test + run the latest ImageMagick release, but can't get hold of it because their Linux distro of choice distributes only older versions.

---

_{(In case you accept and implement this, I volunteer to prepare + publish an short online tutorial about ImageMagick-as-an-AppImage on my ASCIInema channel :) )}

[probonopd]

Given enough interest from this project I'm happy to help doing it.

[urban-warrior]

We propose you and any volunteers set up an AppImage ImageMagick repo and if it proves useful to the community we will consider supporting it as part of our distribution workflow.

[probonopd]

@urban-warrior please see #858; it is no extra build nor an extra repo but merely packages the existing Travis CI build and uploads it to GitHub Releases.

[probonopd]

Thanks for merging @dlemstra. To everyone: Continuous build URLs can be found in the Travis CI build log.