Monogame: Linux Installer: Snaps or Flatpak

[harry-cpp]

I will be doing an update of Linux installer for MG 3.7. Now the current way it's set up is that it uses a .run installer, and it requires a lot of stuff to be the latest version. I can't do much about it and there isn't any backwards compatibility, like for almost all of the distro specific packages. Now in recent months 2 projects have appeared which aren't distro specific and offer backwards compatibility, these 2 projects are:

• Snaps - http://snapcraft.io/
• Flatpak (aka Xdg-app) - http://flatpak.org/

Now one of these should be selected, if anyone has a valid reason to select one over the other, do mention it bellow. Also please avoid selecting one of them because you like one of the contributors of the projects.

[KonajuGames]

A new month, a new installer option for Linux.

These look like new versions of package managers. We would have to ask the user to install snapd or flatpak to install MonoGame with the command-line tool provided by that app distribution service. Is that right?

snapd runs as a daemon, updating apps automatically in the background. I wouldn't feel right asking a user to install a daemon to use MonoGame.

[harry-cpp]

These look like new versions of package managers. We would have to ask the user to install snapd or flatpak to install MonoGame with the command-line tool provided by that app distribution service. Is that right?

Snaps come pre installed on Ubuntu 16.04 http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages

[harry-cpp]

Also flatpak support will be in GNOME Software Center 3.22 so they will be easy to install as well.

[KonajuGames]

Snaps come pre installed on Ubuntu 16.04. Flatpak don't.

That's less of a barrier then, but only for Ubuntu 16.04 users.

Also flatpak support will be in GNOME Software Center 3.22 so they will be easy to install as well.

If snaps support is already in Ubuntu 16.04 and flatpak support is still coming, it would make sense to go snaps if we had to choose one. I still feel uncomfortable asking a user to install a snaps daemon on every other distribution in order to install MonoGame. Snaps requires the distribution to support LXD, a container hypervisor. That's another barrier.

Flatpak prefers having the app in a repository rather than standalone. From the FAQ: "Note that bundles have some drawbacks, compared to a repository", but it doesn't list the drawbacks. It appears snaps also assumes you're going to be uploading the app package to a repository.

Both of these appear to have a lot of baggage, and may not even be supported on a user's distribution due to their requirements. I can't say that I'm comfortable with either of them at this stage.

How long until snaps and flatpak are superceded by the next package manager?

[harry-cpp]

Do note that I don't plan on dropping .run installer, I just want to add an extra method of install.

[InfiniteProductions]

@cra0zy: that's good, because reading previous talks I just think: with this it shouldn't be called "Linux" version but Ubuntu version, which would be more accurate.

And, I'm not sure Ubuntu is the most used Linux distro among MonoGame users, it would be interesting to ask them maybe.

[diazbastian]

@KonajuGames So far, Flatpak is officially supported by some distros and others are yet to come, however the repository offered by Canonical are external and unofficial (Copr, Aur, etc). From my experience, use Flatpak in Ubuntu is the same as any other distro, unlike using Snap outside Ubuntu.

In my opinion, no system is mature, however, Flatpak is superior in features and roadmap promises better options that Snap. In addition, Flatpak is really independent of any distro (included runtimes). Snap must run an instance of Snappy Ubuntu Core to work (a distribution that provides warranty can not take care of a third-party development while offering Snap packages) and sign a CLA agreement because it can only be distributed Snap packages from the Ubuntu Store (centralized repository and closed Canonical server).

Canonical wants to create a Google Play Store more closed and even makes things easier for developers, they take away their independence. Would you ask a user to install an external daemon and use an external software store?

I prefer to download a package directly from the author's website and install it on any distribution.

[harry-cpp]

@diazbastian Those are some excellent points :+1:

@cra0zy: that's good, because reading previous talks I just think: with this it shouldn't be called "Linux" version but Ubuntu version, which would be more accurate.

And, I'm not sure Ubuntu is the most used Linux distro among MonoGame users, it would be interesting to ask them maybe.

I don't use Ubuntu, and I don't even test the installer on Ubuntu... I don't get why it would be called that...

[tgharib]

+1 to this. I dislike that I have to download and run a binary which touches my system files. I also don't like the fact that I have to install the dependencies and I have to keep track of them (to uninstall) when I remove MonoGame. I don't really have any preference one way or another but it seems that snaps require only 1 command to install whereas flatpak might require 3 or more commands to install. Still, either way is better than what we have now. I'm running Manjaro (Arch derivative) if that matters.

[harry-cpp]

@cra0zy which distro do you use? mine (ubuntu 14.04) don't have packages referenceassemblies-pcl nor mono-pcl.

You need to add mono repo. http://www.mono-project.com/docs/getting-started/install/linux/#debian-ubuntu-and-derivatives

[harry-cpp]

Flatpak wins.

[probonopd]

@diazbastian

I prefer to download a package directly from the author's website and install it on any distribution.

Me too. Have you checked AppImage? One app = one file, no installation, no system files touched, no runtimes, runs on most distros without needing to install someting first. Truly distro-independent, community-driven.

[diazbastian]

@probonopd Do you have a algorithm for detection of discussions?, you usually appears in every discussion about Snap or Flatpak. I've already said before, AppImage was a good idea, but never not finished off. Currently all the support and attention are elsewhere and my preference is Flatpak for its technical characteristics and projection.

[harry-cpp]

@probonopd I checked out AppImage before (mostly since I use Etcher) and as you said, it's not an installable package, which immediately makes it bad for this type of project.

[probonopd]

@cra0zy

it's not an installable package, which immediately makes it bad for this type of project

Can you explain why you think this is so?

[harry-cpp]

Can you explain why you think this is so?

Because you want to integrate it with system MonoDevelop, add a mgcb compiler command, integrate it with system Rider IDE if installed, add .mgcb mime type... the list goes on....

[probonopd]

Thanks for the explanation. There are different objectives for the various systems. For example, I would like to grab a random Live CD, boot into it, download exactly 1 file that contains the IDE and SDK and whatnot, and be able to do my development... but different people have different priorities, and that is fine.

[harry-cpp]

So... I thought I would write some thoughts on packaging up games on Linux here using the mechanisms mentioned above:

• flatpak - SDL can't access joysticks when inside flatpak... its not an SDL problem, its a flatpak problem, it does not expose udev... great... :/
• AppImage - Serves the same purpose as if you were to put the files into an archive, unless you have the optional "appimaged" service running. This technology would be very interesting if it had a very standardized way of installing stuff.

Well, I guess its time to try snapcraft, fingers crossed.

[probonopd]

This technology would be very interesting if it had a very standardized way of installing stuff.

Can you please elaborate what exactly you are missing? Possibly it's already implemented...

[harry-cpp]

Can you please elaborate what exactly you are missing? Possibly it's already implemented...

A way to install the appimage content into the system (without writing your own installation script or having to use appimaged service).

[probonopd]

@cra0zy and what is the reason that you would want to "litter" stuff into the system (as opposed to keeping it neatly bundled inside a compressed filesystem image all the time)? I'm genuinely interested in your use case.

[harry-cpp]

@cra0zy and what is the reason that you would want to "litter" stuff into the system (as opposed to keeping it neatly bundled inside a compressed filesystem image all the time)?

• Who would want to put a game into a compressed filesystem? It sounds like a horrible idea for performance, and a pretty much unacceptable idea when the game is big enough...
• I, like many other people, like having stuff installed into their systems, having proper app launcher, having a terminal command, having mimetype integration, etc.
• I can't believe I'm saying this, but MacOS has a very good implementation of what you are trying to do with their .app containers (which yea, I know, they are just folders)

[probonopd]

Who would want to put a game into a compressed filesystem? It sounds like a horrible idea for performance, and a pretty much unacceptable idea when the game is big enough...

Is this based on experimentation or just a general statement? Because in my experience, performance is not necessarily "horrible", but I guess it depends on the exact payload, so ymmv.

I, like many other people, like having stuff installed into their systems, having proper app launcher, having a terminal command, having mimetype integration, etc.

The optional appimaged daemon takes care of 1 and 3, and 2 can easily be achieved by moving the AppImage to a location that is on your $PATH (e.g., /usr/local/bin if you want to make the game available to all users of the computer).

I can't believe I'm saying this, but MacOS has a very good implementation of what you are trying to do with their .app containers (which yea, I know, they are just folders)

Agree, the Mac really shines in this area. By the way, you can unpack an AppImage to the filesystem by using its --appimage-extract option. Then you essentially have something _very_ similar to the Mac. With ROX Filer can even have it interpret the AppDir as an opaque object rather than a folder.

That being said, I respect your opinion that you prefer a traditional installation. I was just genuinely interested why someone would prefer that.

[harry-cpp]

Is this based on experimentation or just a general statement? Because in my experience, performance is not necessarily "horrible", but I guess it depends on the exact payload, so ymmv.

The bigger the game, the slower it becomes, its just a general statement.

The optional appimaged daemon takes care of 1 and 3, and 2 can easily be achieved by moving the AppImage to a location that is on your $PATH (e.g., /usr/local/bin if you want to make the game available to all users of the computer).

The problem is that you need to know about its existance, unless each dev decides to bundle it up inside their AppImage.

Why don't you just offer up a dialog that ask if you want the AppImage to be installed into the system or if you want to run it (with a checkbox to remember the action for the selected appimage)?

• You could have an environmental variable that states ALWAYSRUNAPPIMAGE for the old behavior
• If you install it, it should get extracted to a folder like on MacOS, that way you get the performance benefit

[harry-cpp]

And my conclusion for snaps is...:

~/SnapcraftTest > snapcraft
Native builds aren't supported on Fedora. You can however use 'snapcraft cleanbuild' with a container.

[harry-cpp]

Gonna close this one, both flatpaks and snaps suck as of this moment, hopefully one of them improves in the future.

[scx]

@cra0zy

• flatpak - SDL can't access joysticks when inside flatpak... its not an SDL problem, its a flatpak problem, it does not expose udev... great... :/

As far as I know, joysticks should work as long as you give it --devices=all permissions.
https://github.com/flatpak/flatpak/issues/7#issuecomment-346523979
https://github.com/flathub/io.gitlab.jstest_gtk.jstest_gtk/blob/82cc5b28a3324ddf186e994fc2a0b8e94b1d359f/io.gitlab.jstest_gtk.jstest_gtk.json#L10
https://github.com/flathub/io.gitlab.sdl_jstest.sdl2_jstest/blob/cf4d07cea6efb0e2e3954ed64b034dfc05d353a3/io.gitlab.sdl_jstest.sdl2_jstest.json#L8

You could even test it by yourself:
https://flathub.org/apps/details/io.gitlab.jstest_gtk.jstest_gtk

[harry-cpp]

Nah, flatpak is still missing proper access for udev, however if you build SDL without udev you'll be mostly fine. I have already published a nuget that allows automatic packaging of MonoGame DesktopGL games here: https://www.nuget.org/packages/MonoGame.Packaging.Flatpak/