Possible Duplicate:
What’s the best way to distribute a binary application for Linux?
We would like publish a proprietary game in Linux. The game is relatively simple, has a custom engine written in C++. We have been using the MinGW compiler on Windows and one person does programming and testing in Linux with the g++ compiler.
The game is written exclusively using open source libraries, which are all cross-platform.
What is the recommended way to make a program for Linux work across all Linux distributions without requiring packaging for any of them? The ideal way for me would be to package it as a .zip or tarball and provide that a download, just like good ol’ .exe files under Windows that work with system libraries.
Most games I’ve played under Linux that provide such downloads offer a shell script (which is a compatibility problem in itself!) that launches it. I have no problem with it, but it reeks of user-unfriendliness. Additionally, a lot of games require additional libraries. For instance, SDL 2.0, the hardware-accelerated new-version of the popular library, is not yet available in most distributions’ repositories yet several games are known to use it, and I had to compile it myself. This is even worse.
I would like a solution whereby a customer can click on the binary file in their file manager of choice, and it would run, no ‘apt-getting’ or ‘yumming’ of the necessary libraries. I don’t mind breaking standards, and if it has to go in /opt, it will.
First, you have to understand that “yumming” and “apt-getting” are not really the actual installers of the applications (packages), they are simply the front-end programs used to look up / download / update / trace packages on the repositories (from the distro and others that you manually add). So, when you say “no ‘apt-getting’ or ‘yumming'”, we have to assume that you mean that you don’t want to put up your game on a repository, which makes sense if you want people to pay to get your game (as opposed to other proprietary but free software like flash, graphics drivers, video codecs, and other things you typically find in repositories).
So, there are really just two types of package management systems, RPM and DEB, which use a command-line program,
rpmanddpkg, respectively, to actually do the installation. Most distributions also come with a GUI front-end for those programs too (not the Synaptic-style package management software (which is a GUI front-end to apt-get or yum), but something simpler). When you double-click on a.debor.rpmfile, on most distros, you get this GUI front-end to pop up asking you for admin credentials and telling you about dependencies that are required, and, obviously, that you are about to install this package onto your system. From what I can tell, this is exactly what you want. And so, what you need to provide is a.debfile (for Debian distros) and a.rpm(for Red Hat distros), for both 32bit and 64bit versions of your game, just like I would assume you provide a.msifile for your Windows versions.As for dependencies that might be hard for users to locate. What you should do is include in some directory of your installer a number of additional (‘recommended’ version) packages for these esoteric dependencies so that they can be installed from those offline packages if a newer version cannot be fetched from the distro’s repositories. And that’s about it.
And you can either make people pay to get the deb or rpm installers for your game, or include some kind of license-key system to unlock the game (and thus, make the deb/rpm files available for download, and charge for the key / code to unlock it).
Ideal? Really!?! Yeah, if all you do is use system libraries, then it will work. But if there is anything more, it will be a nightmare (nearly as bad as it is under Windows of you don’t rely on installers).
Make sure none of those open source libraries are GPL-licensed, because if that’s the case, you can’t make your game proprietary. Your dependencies must be licensed under LGPL or BSD, or similar licenses, so watch out for that.