Add packaging support for Linux

[jerluc]

According to the LÖVE wiki documentation on "Game Distribution", there currently is no great support for packaging distributable game binaries on Linux. That being said, I think we can do a bit of fancy repacking of the original .deb file to achieve the same result.

[technomancy]

we can do a bit of fancy repacking of the original .deb file

Do you mean basing it on the files here? https://launchpad.net/~bartbes/+archive/ubuntu/love-stable

I don't know if that will work since there's a huge number of .debs there, and the correct one is selected for you automatically when you query the PPA. Sometimes you will need the updated libsdl2 and sometimes you won't; putting it into a single manually-downloadable .deb collapses all those choices.

Anyway, that is to say that .deb files are really not meant to be manually-installed; they work fantastically with apt-get, but unless you are providing a proper apt repository they are not a good choice.

[jerluc]

@technomancy actually, I'm referring to the .deb files offered for Ubuntu (though it looks like these should mostly just work on any Linux really) on the LÖVE homepage, which may or may not be the same as the packages listed on that page.

Unpacking the download shows a very typical .deb setup with only a few files inside (and honestly it looks like the inner /usr/bin/love is the only thing we care about here). That said, you are right that it might get a bit iffy due to the fact that libsdl2 is dynamically linked to the love binary, but I still don't think that's a huge deal (maybe a simple Makefile/script is used to do the dependency dance, maybe it can just say "Requires libsdl2", etc.).

As for .deb manual installation, this isn't really required, rather I was just trying to reuse the existing dpkg -i my_package.deb sorta jig that most Debianers have gotten used to. However, even a simple install script or even a straightforward makeself binary would suffice.

Since this tool is meant primarily for game developers (such as yourself!), and game distribution to multiple platforms is normally an after-thought, what do you think makes most sense for Linux distribution of a game in general?

[technomancy]

Oh, if you are referring to the official Ubuntu packages, I don't think that's a very good idea as you will be stuck with 0.9.1.

As for .deb manual installation, this isn't really required, rather I was just trying to reuse the existing dpkg -i my_package.deb sorta jig that most Debianers have gotten used to.

What I meant was that this is really not a good way to install programs--the .deb format is designed around repositories, and it's really best used in the context of a repository. Calling dpkg by hand always makes me nervous, and a lot of Debian or Ubuntu users have been burned by shoddily-packaged programs that interfered with the rest of their system packages, and they will be wary of installing a .deb (even if it is packaged in a way that it won't interfere; they don't know that.)

Since this tool is meant primarily for game developers (such as yourself!), and game distribution to multiple platforms is normally an after-thought, what do you think makes most sense for Linux distribution of a game in general?

I would strongly recommend going with a single downloadable file (as statically-linked as possible) that does not not need any root privileges to install. I think you might need different executables for different glibc versions or something, but this way you can support people on Fedora, Arch, etc too. (The whole "Linux just means Ubuntu" notion is rather tired.) Just something you can drop in your ~/bin directory is ideal.

I am creating debian packaging for my game, but that is only because I am hoping that some day it can be included in the Debian repos.

[jerluc]

Thanks for your input @technomancy, I definitely agree with trying to get just a single downloadable file with all dependencies either statically linked or at least self-contained within the extracted files. That's essentially what I meant by "repacking the original .deb" was basically to examine what dependencies are even bundled into the .deb files for LÖVE currently, and repackage them into a tarball of some sort so that someone can just download, extract, and run a binary.

Coming from a heavy Gentoo background, I do completely agree that the use of unofficial .deb files (or all .deb files really) is super sketchy w/r/t the idea that it would just mindlessly extract all of its contents into the root of the filesystem. However, I think it would be reasonable to say that packaging the game in a similar manner (though not using .deb or dpkg, you've got a point there) where all the required dependencies are in the packaged tarball is ideal if possible.

Another added benefit to simply distributing a tarball/zip/etc. is that the user can then choice how and where to put the binaries her/himself. This is a huge gripe I have typically when working with Makefiles that don't respect my configurations for where my binaries go during a make install and I'd rather let users decide for themselves.

That all being said, as mentioned, it looks like the only thing that's even of importance in there is the actual LÖVE binary itself, however, it does look to be dynamically-linked (I believe it only relies on libSDL2 as you mentioned, but also I seem to recall it linking against OpenAL as well?), which may be an issue.

My thoughts around this are basically that we can do one of:

• Output an actual source distro of LÖVE that includes dependency pre-checks and the like, but spits out a LÖVE binary that's compiled with the game sources inside (basically like a Gentoo-style package)
• Output a tarball with a precompiled LÖVE binary, the sources included as a .love file, an actual run script (which is what the user would execute to run your game), and precompiled libSDL2 libraries that we LD_PRELOAD into the binary in the run script (gross!)
• Output a tarball with a precompiled LÖVE binary, the sources included as a .love file, an actual run script (which is what the user would execute to run your game), and just some simple README listing out the dependencies

I'm honestly leaning toward the third option, as it's frankly easiest to implement on my end. Furthermore, I would be surprised to find a Linux-based gamer who either doesn't know how to install dependencies on their own distro or who doesn't already have libSDL2 installed from other games.

[josefnpat]

There are some ways to do this.

If you're releasing for linux a .deb is easy (I did it for 0.8.0 and 0.9.x I think). All you have to do is mark the .deb against the "correct" version of love, and leave it to the user to figure out how to add the PPA or install love. You can also make RPM's.

Also, Arch AUR's are easy too - want me to do the AUR?

I also have a script that tells people to install love if you want to do it like that: https://gist.github.com/josefnpat/10cc2a36b62c08d6999d9565402a689f

Otherwise, there are ways to distribute the love binary - the trick is to build them with the oldest version of debian/ubuntu, and just hope that hits most folks.

Of course, most lovers like to distribute a .love but that's not entirely friendly for the rest of the linux community.

For best coverage though, I would release a tar with the binary and the required libs like steam does it. talk to some of the folks who have already gone the distance: http://50.116.63.25/public/notable_love_games.md

[jerluc]

Thanks for the suggestions and offering to help with Arch @josefnpat!

I think I tend to agree with both you and @technomancy in that we should likely at least provide packaging such that Linux users can download a single file (likely a tarball or zip) that can just be extracted and run--essentially all of its dependencies contained within.

That being said, I just wanted to quickly document some of the things that are needed before we get actual Linux packaging support:

• [ ] Adding support for Linux LÖVE binary downloads, per #3
• [ ] Ensuring that we can bundle libSDL2 (and possibly OpenAL if it is a requirement?) within the distributable archive file (maybe this requires the gross LD_PRELOAD hack, or maybe we can have some other cleverer way to handle bundling this dependency)
• [ ] Optionally adding Linux custom icon support per #7 (I'd consider this to be honestly the lowest priority thing on this list, as not all Linux users use a graphical file browser to begin with!)

[jerluc]

I've started work in the linux-support branch by adding download support for both Linux i386 and amd64 precompiled LÖVE binaries. Unfortunately this still cannot be used for lover run or lover dist yet as the package extraction phase in the downloader is not working properly with the pyunpack library. It shouldn't be too hard to get working, just a bit annoying is all :)

[jerluc]

Also note, I just ran into one slight complication with packaging and even just running on Linux from a fresh download.

[probonopd]

The LÖVE documentation mentions:

The AppImage format is a format for packaging applications in a way that allows them to run on a variety of different target systems (base operating systems, distributions) without further modification.

What do you think would it take to bring AppImage from a "good" to a "great" mechanism for packaging distributable game binaries on Linux?