Best Practice for AppImage Distribution

Creating AppImages
1

Hi everyone,

I am responsible for maintaining Cryptomator desktop applications and we’ve decided to switch from the .deb/.rpm/ppa/aur/etc hell to using AppImages for our upcoming release.

Now that I’ve managed to create the AppImage itself on TravisCI (still have some questions, but that would be a different topic), we need to decide what is the best way of publishing it. @probono has suggested to use GitHub releases in this GitHub issue. We’re currently working with Bintray for our Windows and Mac applications.

Bintray is significantly faster (at least in my region) than GitHub Releases, which play a role if central directories such as AppImageHub or eventually package managers link to it.

Furthermore, GitHub Releases only work for tagged commits which requires some extra work for nightly builds (I don’t mean the tagging itself but rather the CI config gets more complex). Having source code and releases on the same service is more consistent, though.

Are there any other binary distribution platforms that might be interesting? What is best suited for integration with AppImageUpdate? Does it matter for AppImageHub where the Binary is hosted?

Once we have published it, what would be the ideal instruction for users not familiar with AppImages? Apart from making the AppImage executable after download, should I recommend saving it to ~/bin as suggested by the Wiki or ~/Applications which is also watched by appimaged? In my opinion ~/Applications would be an easy-to-understand location for technically less advanced users. But Linux purists surely don’t like it as much as ~/bin.

TL;DR:

  1. Where to upload AppImages?
  2. What service is easiest to integrate with AppImageUpdate and AppImageHub?
  3. How do I write good download instructions?
1 Like
2

Hi.
$PATH doesn’t contain ~/Applications by default so, imo, ~/.local/bin it’s a better place (it’s included in $PATH by default).
Due to it’s own nature you could create “an installer” for the users, a simple script that downloads the appimage, chmod to exec and adds a desktop, or at least a “preliminary desktop” (just in case the appimage generates its own desktop after first execution). wget(or curl)+zenity and 5 lines of code (including comments xD)

BTW, you could encourage your users to use appimaged that will take care of all of this questions.

Are there any other binary distribution platforms that might be interesting? What is best suited for integration with AppImageUpdate? Does it matter for AppImageHub where the Binary is hosted?

Github, gitlab… I don’t think that the host will be relevant for appimagehub nor appimageupdater. In my experiencie github (also gitlab) works pretty well, it’s reasonably fast and it’s solid-rock. And having both releases and source the project management it’s easier.

3

Having the AppImages on the PATH is for sure an advantage. But ~/.local/bin is hidden from GUI-only users. Ideally we need a place that satisfies both.

I already thought about adding a single-line copy-paste install script that you can just paste into your terminal, just like Homebrew does. The downside is, that this trains users to blindly execute any potentially malicious terminal commands they find in the internet.

I will for sure recommend also installing appimaged. Let’s hope for it to be included in many distributions as soon as possible. But I like the fact that it is not strictly required. This is the main benefit over snap or flatpak.

If AppImageHub or AppImageUpdater (or other services) don’t extract version information or other metadata from GitHub Releases, we will stick with Bintray for now.

4

That’s a very good point but if a “installer” is a bad thing, download to .local/bin is not an option and download to a “non-PATH” dir is a bad option… then I will take the “lesser bad option”.
If a user downloads the appimage to ~/Downloads, or any other folder, he only needs to right click->permissions->mark executable. The good thing: the user has full control and there’s no “bad training”. The app will not be in the path (perhaps isn’t really important) but any user could create a launcher from its DE, and also it’s possible than the appimage creates its own desktop when first launched.
If a user downloads to ~/.local/bin then it must activate the “show hidden files” and although he has the app in the PATH if he wants to launch the app he needs to create the launcher and mark the app as executable (as in above case) so there’s no advantages (despite the PATH thing… but thinking twice about it isn’t really important).
If the user downloads an installer he must mark the installer as executable and has no control over where the appimage is installed. It’s true that in this case you have more control and can create the desktop, set as executable or whatever but the differences with first case are minimal from the user’s perspective.

In conclusion, and in my opinion, it’s better to let the user download the appimage where he wants and give some instructions (for cli and gui) to make it executable and create a launcher. In any os the user must do at least one action in order to get apps installed so the “problem” really it’s not that big.

Cheers

5

Welcome to AppImage, glad you like our distribution-independent approach.

I don’t think there is an “absolute” best way - the best hosting option depends on your requirements. I am mainly using GitHub Releases and Bintray, and I see pros and cons with each. Others like to host themselves, and also have good reasons for that.

If you are happy with it, then I’d say stay with it for Linux, too.

Both are equally suited. Any hosting is, really, as long as it properly supports HTTP Range Requests (which most servers do).

Conceptually no, although AppImageHub currently has some more knowledge about projects hosted on GitHub Releases (e.g., can extract the link to the author page, etc.).

Once we have published it, what would be the ideal instruction for users not familiar with AppImages?

You can link to (or copy and paste from) How to run an AppImage.

Apart from making the AppImage executable after download, should I recommend saving it to ~/bin as suggested by the Wiki or ~/Applications which is also watched by appimaged? In my opinion ~/Applications would be an easy-to-understand location for technically less advanced users. But Linux purists surely don’t like it as much as ~/bin.

AppImages are designed so that they can run from any location in the filesystem, although our optional appimaged daemon (due to technical restrictions) only monitors the locations listed at GitHub - AppImage/AppImageKit: Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat.

1 Like
6

Noooo – please don’t, as that would take away many of the advantages that come with AppImages.

It’s really up to the user – some might also want to put it in /usr/local/bin to have it on the $PATH for all users…

1 Like
7

That’s true and that’s what I also said at my “conclusion”, but my experience says me that not all users are used to the “free way”. Some of them appreciate the simplest way, although it could result in a lose of advantages or in a completely misuse of an app, technology, whatever…

One time I’ve an user that pretend to update one machine installing the software into another machine… After years seeing things like that I’ve become more practical and less “ethical”.