Linux Game Development - Dependency Management

Question

I'm working on a game that I'm trying to build for Linux and distribute via Steam. At present, there are some dependency issues and I'm wondering about the best approach:

1. Bundling .so files with the executable (Is bundling legal/safe? The libraries in question are libopengl.so.0, libopenal.so.1, and libsteam_api.so which I'm less concerned about)
2. Including a shell script to check for/prompt installation of dependencies (I can apt install all the necessary dependencies, of course. But I want to be respectful and not force install of something without permission.)

Assuming that we're bundling one or more .so files, I'm unclear on whether LD_PRELOAD or LD_LIBRARY_PATH is the preferred approach to inform the executable about their presence. Which is preferable?

Answer 1

Is bundling legal?

That depends on the license terms of the library. For example, the GPL says that if you use a GPL-licensed library then your whole game must be licensed under the GPL, while a LGPL-licensed library permits you to bundle your libraries with non-GPL software as long as they are dynamically linked.

Is bundling a good idea?

Yes. There are lots of good reasons for operating systems to manage libraries in a centralized manner. But gaming isn't one of them.

• Giving the user the ability to patch libraries system-wide independently from the applications which use them does not matter, because games are usually not run on high-security systems and usually don't act as public servers (game servers are of course another subject).
• Storage space does not matter, because games usually take gigabytes of storage anyway. A couple MB of redundant libraries is not going to matter.
• What does matter for games, though, is having a robust, idiot-proof setup which just works out-of-the-box without the user having to tinker with anything. Shipping your game with all its libraries included makes sure that the game won't malfunction because the end-user happens to have a newer version of a library which happens to work just a slight bit different. Every possible point-of-failure of your game installation process means you are going to get a couple more negative reviews saying "Does not run - refunded". So you want to minimize them as much as you can.
• When you use Steam, you can't install system-wide libraries because you don't know which package manager is used by the Linux distribution the user is using. apt is not the only package manager. There are also pacman, yum and a lot more exotic options. You can't possibly write an install script which detects and supports them all. Technically Steam is also a package manager. But its ability to install system-wide libraries is limited to the list of "Common Redistributables" provided by Valve. You can handle dependencies shared between Steam games using "Shared Depots". But in order to share these dependencies, you need to have control over all the games making use of them. So if you plan to release a lot of games which all use the same versions of various libraries, you could theoretically turn those into a shared depot so players who install more than one of your games don't need to download your libraries twice. But I doubt it's worth the effort, because again, libraries are rarely the bulk of a game download. Shared depots are mostly intended for shared assets.