New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide FreeOrion AppImage #1236

Open
probonopd opened this Issue Jan 22, 2017 · 9 comments

Comments

Projects
None yet
4 participants
@probonopd
Copy link

probonopd commented Jan 22, 2017

Providing an AppImage would have, among others, these advantages:

  • Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Just one format for all major distributions
  • Works out of the box, no installation of runtimes needed
  • Optional(!) desktop integration with appimaged
  • Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can GPG2-sign your AppImages (inside the file)

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Here is a proof-of-concept FreeOrion AppImage, expected to run on 2014-ish and later distributions:
https://bintray.com/probono/AppImages/FreeOrion#files

It gets generated from the binaries in the trusty ppa using this configuration:
https://github.com/probonopd/AppImages/blob/master/recipes/meta/FreeOrion.yml

I quickly tried it on Fedora 25 but it is expected that some fine-tuning still might be needed for some distributions.

Do you think this would be useful?
I'd be happy to help producing an official AppImage.

@probonopd

This comment has been minimized.

Copy link
Author

probonopd commented Jan 22, 2017

Seeing that you are already using Travis CI, it would also be possible to bundle up each of those builds as an AppImage. Together with the binary delta updates, users could go from build to build by downloading just the few MB that would change between builds.

@probonopd

This comment has been minimized.

Copy link
Author

probonopd commented Jan 28, 2017

@adrianbroher @geoffthemedio did you have a chance to try out the proof-of-concept FreeOrion AppImage? What do you think?

@adrianbroher

This comment has been minimized.

Copy link
Contributor

adrianbroher commented Jan 28, 2017

@probonopd I don't care about this technology and @geoffthemedio uses Windows only afaik.

@geoffthemedio

This comment has been minimized.

Copy link
Member

geoffthemedio commented Jan 28, 2017

I have no idea how to provide an AppImage and I assume no way to test one.

@Vezzra

This comment has been minimized.

Copy link
Member

Vezzra commented Jan 29, 2017

That's one of several technologies aiming at providing self-contained application packages for Linux, which contain all dependencies and therefore are independent of external libraries etc. Flatpak, Snap, Zero Install etc. are other examples/approaches, most if them also aiming at being distribution independent.

These approaches of course have a certain appeal, as it provides application developers with convenient means to deploy their stuff more easily on Linux, without having to actively maintain packages for each distribution, and not to worry about compatibility issues with various versions of external libraries their app depends upon.

However, we don't maintain any packages for any Linux distros anyway (we simply don't have the resources to do that), all FO packages in the repos of the different distros are maintained by people who decided they want a FO package for their distro.

We only provide install packages for Windows and OSX so far, which is done by me (in my capacity as Packager and Release Manager). As far as I can see, providing an AppImage for FO would be my responsibility (as @adrianbroher already made clear he won't do that, and @geoffthemedio can't because he is on Windows), and I have to confess although I know roughly what it's basically about, I don't know anything about producing/maintaining these AppImage packages.

As long as it's fairly easy and straightforward to produce/maintain an AppImage, I might consider doing this, as I do have a Linux system I can use for this. However, I've already far more on my plate than I can handle, and I only have this Linux system for testing purposes, I'm far from being proficient in Linux, so I can't provide much assistance when it comes to fine-tuning for specific distros.

So, as appealing as the idea might be, it's not high priority for me. Meaning, I can't go through substantial efforts to be able to do this (at least not anytime soon).

However, nothing keeps you from creating and maintaining an AppImage for FO, if you want to do it. We can probably even provide a link on the main page of our wiki to the location where you intend to provide the AppImage(s), (if that's ok with you, @geoffthemedio).

@geoffthemedio

This comment has been minimized.

Copy link
Member

geoffthemedio commented Jan 29, 2017

sure

@Vezzra

This comment has been minimized.

Copy link
Member

Vezzra commented Jan 29, 2017

@probonopd, the AppImage works fine on my Linux system (Kubuntu 16.04). So far it does indeed look good.

There is, however, one big issue with deploying FO like this: I don't see a way how users/players can access the game content folder (as it's contained with everything else within the AppImage file), which prevents them from customizing the game.

@probonopd

This comment has been minimized.

Copy link
Author

probonopd commented Jan 29, 2017

@Vezzra it looks like you are already using Travis CI to do builds; these could be bundled up as AppImages with no manual effort (just write the script that does the packaging once, like these projects do).

How common is the use case that users need to modify something in the game content folder? Where is it installed on regular systems, where non-admin users also cannot modify anything in /usr? One way for an user wanting to modify the contents of that folder would be to loop-mount the AppImage, copy out its contents (essentially an AppDir), and do the modifications. The user might or might not choose to re-package the AppDir to an AppImage again.

@Vezzra

This comment has been minimized.

Copy link
Member

Vezzra commented Jan 29, 2017

The Travis CI thing has been set up by @adrianbroher, so any fiddling with that would have to be done by him (I won't touch anything there as I don't know what I'm doing). Also, looking at the scripts you linked doesn't help me much, I'm clearly out of my depth here.

Sorry, currently I don't have the time to wrap my brain around this technology. But we can leave this feature request open, maybe I manage to come back to this at some point. No promises though, I have already a huge backlog of things I should attend to, and currently it looks like as if I can't catch up... ☹️

Wrt modifiying the game content folder: As long as there is a sufficiently simple and easy way to at least get at the contents of that folder so you can copy them to another location and modify them there, we're good. FO has an option that allows you to specify the where the game should look for the content files. Most players won't want to customize the game content anyway, but it shouldn't be too hard to do for those who do.

@Vezzra Vezzra added this to the post v0.4.7 milestone Feb 12, 2017

@Vezzra Vezzra removed this from the v0.4.8 (mandatory) milestone Oct 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment