Please provide an AppImage for OpenRA

[fusion809]

Hi,

I've noticed you provide Debian packages for OpenRA builds, but I was wondering if you could provide something that would benefit users of even more Linux distributions: an AppImage (website: https://appimage.org). AppImages are a type of cross-distribution packaging format that need not be installed in order to be run. All they need in order to be run is to be made executable (with chmod +x) and executed.

Thanks for your time,
Brenton

[pchote]

If you can get the appimage packaging working under Ubuntu 14.04 then I'm happy to help with integrating it into our automated packaging and the website download page.

It looks like your main issue with referencing/packaging mono rather than with OpenRA specifically. Do you know if any other projects that use the mono runtime have created appimages?

[fusion809]

I'm afraid not. An unofficial effort (i.e., unrelated to Xamarin or any MonoDevelop developers) was made to package MonoDevelop using an AppImage but it too failed (if you're curious about the details they're mentioned in this script).

[fusion809]

I would settle if another cross-distribution format could be built and provided for OpenRA. Like MonoDevelop preview builds are distributed, officially by Xamarin, as a Flatpak package. If something like that could be done for OpenRA I'd be happy.

[phrohdoh]

Flatpak is all the rage recently and from my limited experience is very similar to the NeXTSTEP/OS X/macOS app format, so would probably be easiest to support.

Would we need to use mono-kickstart with AppImage or Flatpak (or ...)?

[fusion809]

For my part, I haven't the foggiest. I'm not a mono developer myself, I have minimal understanding of C# and related lingos. @probonopd You thought this might be required to get MonoDevelop working as an AppImage didn't ya?

[probonopd]

AppImage is much more like macOS .app .dmg

[pchote]

I'd much prefer AppImage over Flapak at this point: it is much simpler and doesn't force people to install other dependencies.

[probonopd]

There are (at least) two ways to do the AppImage:
a) use existing deb/... packages and convert them to AppImage
b) Bundle up the Travis CI build artifacts as an AppImage

Which route do you want to go?

[pchote]

I suspect the best option might be to bundle the upstream mono deb packages (http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives) and then install OpenRA over the top either using our deb or our makefile.

[pchote]

For completeness, this is related to #12170 (similar issue for OSX) and #11133 (focused on getting in the ubuntu software store instead of cross-platform compatibility).

[probonopd]

I suspect the best option might be to bundle the upstream mono deb packages (http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives) and then install OpenRA over the top either using our deb or our makefile.

Doing exactly that in AppImageCommunity/pkg2appimage#106 (comment) - works but keep getting "Downloading Quick Install Package. Error: An error occurred performing a WebClient request". Any ideas? Shouldn't the data it is trying to download be included in the deb from http://www.openra.net/download/ to begin with?

[fusion809]

Because I have been asked to add yet another mention to this issue of AppImageCommunity/pkg2appimage#106, I am. I have been having great difficulty getting an AppImage to work for OpenRA due to the fact OpenRA is installed to /usr/games and AppImages seem to look for executable files in /usr/bin.

[pchote]

This is only done in the .deb packaging (see buildpackage.sh#L26) to fit the conventions for Debian. The makefile defaults to $(prefix)/bin like you'd expect.

[Mailaender]

I have to admit that I am a bit ignorant on this technology as I never heard from it elsewhere. AppImage does not support repositories and automatic updates? If that is the case, I propose #12663 instead.

[probonopd]

@Mailaender AppImage does support binary delta updates and it does not need repositories in the traditional sense to achieve that, because the information where to get the latest version from is embedded within the AppImage itself. Very similar to the Sparkle framework for macOS. I consider that much more easy to use because users don't have to manage repositories, it "just works".

[Mailaender]

I found https://build.opensuse.org/package/show/OBS:AppImage:Templates/AppImageTemplate and it looks kind of straight forward to use to me.

[probonopd]

Yes @Mailaender, @adrianschroeter did all the heavy lifting for building AppImages on OBS, and we announced it last week:
https://speakerdeck.com/probonopd/opensuse-conference-2017-obs-b-appimage

See https://github.com/probonopd/AppImageKit/wiki/Using-Open-Build-Service for how to use it.

[Mailaender]

I am not sure if running post install scripts and system wide configuration is possible. #13539 might have ruled out self-contained app images.

[pchote]

#13539 is specifically for mods/packages that are installed at the system level so that they are automatically available for ingame switching. "Portable" installs don't need to do this, and will be registered for the current user only when they are first launched.

The only thing that changes here is that the appimage needs to tell the engine what script to run on a switch event so that it can mount the image and run the requested mod.

[Mailaender]

Found a howto instruction video at https://www.youtube.com/watch?v=rVj4hTdr72Y by @andisugandi

[probonopd]

And be sure to hang around in #AppImage on irc.freenode.net for friendly community support :-)

[pchote]

OpenRA/OpenRAModSDK#71 adds AppImage packaging support to the Mod SDK. A future step can be to port that back up here, and package a zip with separate AppImages for each default mod.

[probonopd]

Thanks @pchote. Please do not put AppImages into other types of archives such as zip files, however. (Why?)

[pchote]

What is the recommended way to distribute multiple related AppImages together, if not in an archive?

Asking users to download the individual RA/TD/D2K AppImages isn't great because it is inconsistent with our other packaging types which ship the three default mods in the same disk image / installer. Our website download page would need to be redesigned to accommodate 6 different AppImage downloads compared with the simpler release / playtest choice for macOS and Windows.

[fusion809]

I hope @probonopd has an answer to this one as to my knowledge AppImages just execute one binary. I suppose maybe you can get it to launch a popup that asks you which binary within you want to execute.

[probonopd]

What is the recommended way to distribute multiple related AppImages together, if not in an archive?

Two options:

1. Separate downloads for each application. This is most in line with the philosophy with AppImage, which is "one app = one file". But from the above I get that you don't want this.

2. Like with every good rule, there are exceptions, in which it may be desirable not to strictly follow the "one app = one file" approach:

• If one main application calls other helper applications, the helper applications should not be shipped separately but be included in the main application AppImage.
• If multiple applications share a lot of resources, it also may be desirable to ship them in one big AppImage (example: LibreOffice). This may be the case here?

So if you would like to go the second route, put all of your applications into one AppImage and write a custom "menu" GUI that lets the user select one of the tools when the AppImage is double-clicked.

[pchote]

This may be the case here?

Quite the opposite actually. One of the main focuses of development in 2017 was to decouple the different applications to enable a unified installation and integration experience for both official and third party mods. The second route is a non-starter because it regresses this work.

The issue is that OpenRA is philosophically a software collection, and our users expect to be able to download the three default mods in one go. Getting three for one has been a core part of the project's outreach and marketing. For example, this is how the macOS disk image looks:

Providing separate AppImage downloads is the easiest and cleanest option from a technical perspective, but it is sad to break tradition and I expect it will generate some complaints from users. The extra work to redo the download page will delay being able to adopt this, but on balance I think AppImages are still going to be worthwhile.

[pchote]

If zsync can deal with http redirects then we can follow the approach from OpenRA/OpenRAWeb#369 to manage the update metadata:

• Run zsyncmake during the packaging on travis and push the .zsync files to the release next to the AppImages.
• Generate an appimageversions.json during the website compilation that lists paths to the .zsync files for each mod in each channel (release/playtest).
• Add an appimagecheck endpoint to the master server that accepts a mod and channel argument (again, similar to versioncheck) and redirects to the appropriate .zsync file.
• Embed update paths of the form zsync|http://master.openra.net/appimagecheck?mod=ra&channel=playtest in the AppImages. If the format requires paths ending in .zsync then we can use mod_rewrite to rewrite paths from the form zsync|http://master.openra.net/appimagecheck/ra/playtest.zsync.

[probonopd]

@TheAssassin the above sounds fairly involved to me, can you have a look here please?

[TheAssassin]

@pchote did you try this? It should work fine already. zsync2 has been tested for redirection support very well.

[pchote]

Not yet. At this stage I'm just collecting ideas for when I have time to implement this.

[TheAssassin]

All right. Please let us know whether it works for you. I'm pretty confident it will.