Citra: Please provide an AppImage for Linux

[probonopd]

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
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

The linuxdeployqt tool makes it easy to bundle Qt-based applications in AppImage format.

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

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

Reference: https://www.reddit.com/r/Citra/comments/63y6zv/linux_mint_user_here_what_to_do_about_glibcxx/

[ghost]

I support this as GLIBC depends on the distribution that's getting used so if there are interested players they'd have to compile things themselves first which shouldn't be necessary with such software anymore.

[probonopd]

The binaries that get put into the AppImage should be compiled on a build system that has no newer glibc version than the distributions being targeted. On Travis CI, Ubuntu trusty is currently a popular choice, which would mean that binaries compiled on it should run on 2014-ish and later distributions with glibc 2.19 and later.

[j-selby]

So, I should point out that I am opposed to AppImage as a whole, but I don't want to start a debate here.

Regardless, Citra has a few problems currently in relation to AppImage (using LinuxDeployQt), at least from my end (Fairly new Ubuntu Server 16.04, I'll get back to you on 14.04 when Aus internet starts working):

• Fails to link to PulseAudio. Can be fixed by manually copying /usr/lib/[...]/pulseaudio/libpulseaudiocommon-*.so to the lib/ folder. Seems like this should be automated, like the rest of the libraries used.
• Qt fails to load xcb - doesn't copy plugins correctly, though it does seem to create the plugins/ folder fine.

Process followed:

• \
• mkdir build + cd build
• cmake .. + make -j8
• mkdir dist + cp ../dist/* dist/ (Contains citra's .desktop, mandocs, icons, etc) + cp src/citra_qt/citra-qt dist/ (Main binary)
• \
• linuxdeployqt-[..].-x86_64 -appimage citra-qt
• ./Citra-x86_64.AppImage
• \

[j-selby]

Citra's SDL version works fine with AppImage, using the same process above (I haven't tested any application to emulate, but starts up fine).

[probonopd]

Which OS, OS version, Qt (distro or upstream), Qt version do you use?

[JayFoxRox]

There are 2 important aspects here which are usually ignored:

• Citra Nightly Builds and Bleeding Edge are non-stable builds. They are not necessarily intended for inclusion in distributions or widespread use. As Citra is still in development we should expect users / devs to be willing to compile it on their own so they can help. In my opinion we don't need binary unstable releases at all
  If we have stable builds there should be more docs and a different release mechanism / format. However, no such stable build is currently being discussed.

• Distribution is something that's responsible of the app developer on some OS (namely macOS and Windows), but responsibility of package maintainers of the OS (most Linux distros) or even the community (a lot of Linux distros).
  We should not have to worry about how Linux maintainers package our tools specifically.
  We should only recommend / set packaging standards, but not provide packages binary for Linux distros ourselves. Doing it would open a can of worms.

Another aspect is that Citra does currently not run out-of-the-box and needs bios-like files.
As we are still lacking UIs for such infomation I'd rather avoid distributing it through other channels, other than our website (which contains an FAQ and Wiki detailing these things).

---

Aside from that, I'm also opposed to the idea of AppImage - it's up to distros to embrace projects like it and set a standard for distribution. It's not up to us to decide. If you think we should be using AppImage, just tell your distro maintainers or maintain your own Citra AppImage packages (build on a trusted machine like travis)

[probonopd]

Distribution is something that's responsible of the app developer on some OS (namely macOS and Windows), but responsibility of package maintainers of the OS (most Linux distros)

This is what we can now change using AppImage, Flatpak, and Snap, since that model does not scale well and has prevented Linux to win market share on the desktop in the past.

Finally upstream application projects can provide, in addition to macOS and Windows builds, also their own Linux builds that, and many already do.

[j-selby]

/etc/lsb-release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

qmake -v:

QMake version 3.0
Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu

Installed via apt install qt5-default. Citra uses the system QT libraries on Linux.

Our build guide, with all dependencies and steps, can be found at: https://github.com/citra-emu/citra/wiki/Building-for-Linux

[probonopd]

Seems to be a bug in linuxdeployqt. Right now I'd recommend to compile on Travis CI trusty with Qt 5.8 for /opt Trusty, as this is what I am testing linuxdeployqt with mostly.

[j-selby]

Ok. Travis is now (finally) exporting AppImages on my repo - https://github.com/j-selby/citra - _These builds are not supported in any way by the Citra team_, blah blah blah. I haven't tested emulation, but QT opens fine.

---

I am reluctant to PR this into Citra master for a few reasons however:

• Travis does its best work when we are _testing_ Citra. The whole point of the platform was to give a automated means of doing so. We shouldn't trust automated builds from Travis - that job should be left to a package maintainer when we are actually dealing with users.
• We should not be responsible for every single platform out there. Binary applications cannot guarantee compatiblity with different distributions, even with included libraries. For example, AppImages don't include GPU blobs, and Citra generally needs more up-to-date ones here. Where are we drawing the line here?
• Issues with AppImage itself:
  
  
  
  • Security
    
    
    
    
    
    • AppImage seems to suffer from the idea that security should be opt-in, rather then opt-out. With conventional package management, you generally know at least that the package came from the author(s), which establishes trust. AppImages introduces a trust level corresponding to how things work in Windows - i.e. no implied security at all. In this sense, users are always dumb - make them agree to losing safety explictly. With xdg-app or whatever it is, we can establish a level of security through trusted repositories and sandboxing.
    
    
    
    • Firejail doesn't seem like the ideal solution at all for sandboxing. It seems to have profiles for different applications, which specifies what each should do. What happens if I spoof, say, Chrome, which might have greater permissions then default? Further, users have to explicitly use Firejail. 99% won't.
    
    
    
    • If, say, OpenSSL gets Heartbleed 2.0, we are going to need to individually update every single app out there. If a user doesn't update, they remain vulnerable, even with rapid updates through standard package management. If we have to respond to every single broken dependency out there, we are going to spend the rest of our lives trying to fix something. Further, IMO, updating should be centralised - how are we going to know that /etc/randomapplication/java/whatever/grab-screenshot.AppImage is updated?
    
    
    
  
  
  • Fundamentally lazy
    
    AppImages encourage laziness. Users download once, and forget. When their downloads folder is filled up with GIMP, Blender, Chrome, etc, things start to become a mess. Especially when versioning plays into it.
  
  
  • Filesize
    
    If I wanted to download different versions of Citra - Bleeding and Nightly for example, I'm going to have ~100MB of data sitting on my computer. AppImages encourage file bloat by not sharing libraries and other resources that don't change. I believe that some of the newer container stuff (OverlayFS?) does that for you.
  
  
  • Hackish
    
    This is more of a personal complaint, but AppImages seem to be held together by magic and sorcery. Even the Travis build above had to manually move around SDL libraries. This seems like a really bad idea for developers to be having to copy around stuff. Teething problem, maybe, but applications should be designed for containers, not the other way round (kinda ironic considering that we are an emulation project, but w/e).
  
  
  • AppImages are only a temporary solution
    
    Snap, xdg-app/whatever else will eventually become standard (hopefully). AppImages are not a complete solution, and half-assed software tends to become stuck in the computer world, even when there are better alternatives out there.
  
  

---

If Citra was to go down this path of offering Linux binaries, we should be providing xdg-app or snap images (or, failing that, templates), which have enforced trust, better management of versioned applications, etc.

[probonopd]

Thanks @j-selby for providing AppImages. On ubuntu-16.04-desktop-amd64.iso I am getting

me@host:~$ /home/me/Downloads/Citra-x86_64.AppImage 
/home/me/Downloads/Citra-x86_64.AppImage: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/me/Downloads/Citra-x86_64.AppImage)

which usually implies that the AppImage has been built on a build system newer than Ubuntu 16.04. For this reason I genereally recommend to build for the oldest still-supported LTS release. Which version of libstdc++6 was used for building this?

__EDIT:__ May be related to https://github.com/crapp/labpowerqt/issues/7

[probonopd]

(tl;dr: Thanks for providing an AppImage but I disagree with most of your statements regarding the AppImage format itself.)

Let me respond to your more general points (but note that I am biased as the AppImage core developer):

Travis does its best work when we are testing Citra.

Yes, but in order to really test (manually, on real-life systems) the build artefacts, you need to provide them for download so that testers can get and run them. AppImage makes this easy. (Testers could even unpack the AppImage, effectively turning it into a directory.)

We shouldn't trust automated builds from Travis - that job should be left to a package maintainer when we are actually dealing with users.

My personal opinion is exactly the opposite. While I _do_ trust application authors that they can build their software in the way it is intended to be built, and I trust software that I can see the full build log trail and source code of, and can match source code and build products, I am much less inclined to trust _some random_ guy's build just because it appears in _some random_ repository.

We should not be responsible for every single platform out there.

If the application authors don't support at least one official build, who should then? As a user it gives me a lot of trust to download a binary from _the authors_ and know that any issue can be discussed directly with the authors.

Binary applications cannot guarantee compatiblity with different distributions, even with included libraries. For example, AppImages don't include GPU blobs, and Citra generally needs more up-to-date ones here. Where are we drawing the line here?

Just like on Windows and macOS, you should define _System Requirements_ and ideally have a dialog box point out which ones are not fulfilled on a target system, if the target system does not meet the criteria defined. E.g., "Citra needs GPU XY library version X.Y but your system only provides Z. Please update your system". This is what applications on Windows or macOS would do, anyway.

AppImage seems to suffer from the idea that security should be opt-in, rather then opt-out.

AppImage does not equate forced sandboxes with _security_. If you do not trust the authors of an application, then you should not be running this application in the first place. Forced sandboxes are _dangerous_ because they provide false security to users. It is proven that at least under Xorg, there is no real sandboxing security. Sandboxes can, at best, provide an additional safety net.

With conventional package management, you generally know at least that the package came from the author(s), which establishes trust.

I think the opposite is true. with conventional package management, you can either

• __Get the package from the distribution__, if it is in the repository. More often than not it isn't, or it is only in an outdated version. This is especially true for mature LTS or enterprise distributions. Even if the package is available, it is not clear whether it was built as the original application developer intended it to be built, or whether the distribution has made unauthorized changes. There are many instances where upstream application authors asked distributions to _no longer distribute_ their applications, or at least change the name, because the application authors did not endorse the changes made by distributions. As a user, I want the application exactly in the way the upstream authors wanted it.
• __Get the package from third-party repositories such as PPAs__. If you do this, then you give the repository full root access to your machine, the pre- and postinstall scripts could do _anything_ on your machine _with root rights_. With AppImage, in contrast, the application only has normal user rights and cannot make other changes on the system.

AppImages introduces a trust level corresponding to how things work in Windows - i.e. no implied security at all. In this sense, users are always dumb - make them agree to losing safety explictly.

No: In Linux, the user has to explicitly set the executable bit before anything gets executed. It is implied that by doing this, the user _thinks_ about what he is doing. E.g., download applications from the original author or other trusted locations than from random sites. Using repositories does not change this one bit; using some random PPA from somewhere is arguably even much worse.

With xdg-app or whatever it is, we can establish a level of security through trusted repositories and sandboxing.

How does the user decide which repository he trusts? In the same way he decides which download page he trusts.

Firejail doesn't seem like the ideal solution at all for sandboxing. It seems to have profiles for different applications, which specifies what each should do. What happens if I spoof, say, Chrome, which might have greater permissions then default? Further, users have to explicitly use Firejail. 99% won't.

AppImage is agnostic regarding sandboxes. I have successfully run AppImages in the Bubblewrap sandbox also used by Flatpak. If Flatpak gets as ubiquitous as you assume, then it will be no problem to use Bubblewrap as the default sandbox for AppImages.

If, say, OpenSSL gets Heartbleed 2.0, we are going to need to individually update every single app out there.

No. Central system libraries should be managed by the operating system and not be bundled with applications. So you would only need to update the AppImages the authors of which have decided to bundle their own private versions of OpenSSL for whatever reason. Same for other basic system-provided libraries like glibc and friends. The same is true on Windows and macOS too - libraries bundled privately with applications need to be managed by the applications.

If a user doesn't update, they remain vulnerable, even with rapid updates through standard package management.

I have never seen the latest version of anything for LTS or enterprise distributions.
If you don't take it from me, take it from __Linus Torvalds__:

"The whole "omg, the sky is falling" security argument is bogus. It's particularly bogus for non-core user-centric applications (ie the stuff that doesn't come with the distribution, and that the distribution makes actively impossible to build)."

If we have to respond to every single broken dependency out there, we are going to spend the rest of our lives trying to fix something.

If we have to build every single version of every single application out there for every single distribution and every single distribution version out there, then we are going to spend the rest of our lives trying get that application out to all Linux users.

Further, IMO, updating should be centralised - how are we going to know that /etc/randomapplication/java/whatever/grab-screenshot.AppImage is updated?

Check the update information that the author has embedded in the AppImage. This is essentially a link to the "latest" version that the application or tools like AppImageUpdate can periodically check to see whether a later version is available, at which point the user can choose to update to it by downloading only the bytes that have actually changed (binary delta updates).

AppImages encourage laziness. Users download once, and forget. When their downloads folder is filled up with GIMP, Blender, Chrome, etc, things start to become a mess. Especially when versioning plays into it.

AppImages promote choice. I always keep 3 or 4 versions of my main applications around, a stable one for productive work, a nightly build for testing, yesterday's nightly build to compare regressions, and maybe the previous version. You call it mess, others may just like to be in control rather than having dictated by a package manger what and what not to have around.

If I wanted to download different versions of Citra - Bleeding and Nightly for example, I'm going to have ~100MB of data sitting on my computer.

Who cares? Storage is almost free.

AppImages encourage file bloat by not sharing libraries and other resources that don't change.

AppImages encapsulate applications by not allowing dependencies other to the base system. The same way as iOS and Android work, by the way. Loosely coupled systems are known to be more robust and allow for greater flexibility.

I believe that some of the newer container stuff (OverlayFS?) does that for you.

No. Flatplak has the concept of runtimes, which means that every time you download a new Gnome application, it may request a newer version of Gnome, which then will be installed in addition to all the versions of Gnome that you already have. So not much difference in the end, besides the added complexity of needing a (for the sake of a better word) package manager to manage the complexity.

This is more of a personal complaint, but AppImages seem to be held together by magic and sorcery.

Not at all. Remember that AppImage is just a self-mounting loopback filesystem that executes whatever _you_ (being the application developer) put inside. You are in _full control_ of how _your_ software works. If _you_ consume libraries, then it is _your_ job to know how they work and how _you_ use them. None of AppImage's business.

Even the Travis build above had to manually move around SDL libraries.

What exactly does that have to do with AppImage? (May be a linuxdeployqt issue, at best.)

applications should be designed for containers, not the other way round

Imho applications should be designed for _platforms_, and _reasonably old_ ones at that. If you do applications in the commercial software world, then you had to write against Windows XP until a few years ago, and now it is more like Windows 7 than anything else. You need to think about which users you want to reach and build against the oldest systems they are still using. You should (and can) expect from any serious operating system that applications written for an older version of the platform will continue to run on newer versions of the platform, and file bugs otherwise.

AppImages are only a temporary solution

Quite to the contrary. AppImages and their predecessors have been around for over a decade now, and I guarantee you to be around for a long time. Unless a format comes around that is clearly superior in every way. I don't see one currently.

Snap, xdg-app/whatever else will eventually become standard (hopefully).

These systems are solving different problems. Take xdg-app/Flatpak, for example. You can't just take Citra.Flatpak, download it, and run it on a Live USB system. You need to install it first. Which is not even possible on Live systems and even if it was, it would vanish after a reboot. Also, once it is installed you can't easily archive it because it is scattered around the filesystem in a gazillion of different places you cannot manage by hand.

Also, these systems don't work well for computers with no network connectivity, because applications tend to require additional downloads in order to fulfil their dependency requirements,

AppImages are not a complete solution, and half-assed software tends to become stuck in the computer world, even when there are better alternatives out there.

We have to agree to disagree here. For me, solutions that require me to fiddle around with repositories, or restrict me to certain versions, or force me to update half of my base system just to run the latest version of an application are "half assed", and the gold standard when it comes to application availability are - like it or not - platforms like Windows, macOS, Android, and iOS. Which all use application bundles not unlike AppImage.

[JayFoxRox]

I think this discussion should be held elsewhere. It's derived very much from: "why would Citra benefit from it" and "how should it be approached". It is now: "Use it, here are reasons" - those arguments should be provided as info material for AppImage, not on an issue tracker.
Also how we do distribution / version names / w/e in general is a whole different subject which should also have it's own issue.

(I'm to blame too, because I probably started this derailing with my first post :P )

[j-selby]

@probonopd The issue here is that Citra requires GCC-5 as a hard dependency - we already enforced that a long while ago. The GCC we are using is tied to this libc++ version, so we either:

1. Need to find a way to get it working with a older libc++, which seems like an awful mess.
2. or move to Clang. Would require time and effort in terms of migrating Travis, updating documentation, etc. EDIT: Edited because I'm an idiot on this one.

If we did want to go with AppImages anyway, I would be voting to ditch support for Ubuntu 14.04/... because of these many build issues which we are having with those older platforms (we already need specialised build instructions for those platforms). The image works fine on Arch, Ubuntu from the last decade (😛), etc. That's just my opinion though on the matter.

(While I still don't agree with the format, I'm really not keen to debate it)

[probonopd]

The GCC we are using is tied to this libc++ version

For running GCC, I guess. But not necessarily for the build products (I assume). Looks like https://github.com/crapp/labpowerqt/issues/7 has found a workaround for this.

[j-selby]

Their workaround used clang. Again, a possible solution, but, as I said before, "would require time and effort in terms of migrating Travis, updating documentation, etc". Possible, sure.

[Saroufim]

Someone already made a flatpak manifest for Citra (https://github.com/TingPing/flatpak-packages/blob/master/org.citra_emu.Citra.json). Perhaps this can be adapted by upstream and then published onto Flathub?

[probonopd]

@Saroufim this issue is about AppImage. For other packaging formats please open separate issues, thanks.