Simplifying distribution: Linux (static)

[gajop]

Ever since we have started using the popular static builds, engine distribution has been much simplified, and gamedevs have been given more control over which version they use.

That said, our static builds still require that the user installs some additional system libs manually (SDL2, openal, libcurl), which complicates distribution. Installing libs is something users might not be capable of doing, or simply they will give up and use something that requires less effort.
Automating distribution to include installing system libs is also difficult as it requires that we invoke commands which are distribution specific (apt on Ubuntu, pacman on Arch, yum on rpm distros, and similar).

Therefore I think we should try to simplify this by doing one of two things:

1) Simply distribute libs with the engine.
This solution will increase the size of the binary, but it will make the process really simple, which is a good thing.
The binaries aren't that large, SDL2 is 1.1MB only. The downside of this approach is that we would have copies of SDL for each engine, but that might not be such a bad thing if different engines depend on different SDL.

2) Have pr-downloader take care of obtaining engine libs.
In this solution, we would have a place in $SPRING_DATA_DIR/libs where we would keep these libs. pr-downloader should also download the required files which are missing, and we should set LD_LIBRARY_PATH to include that.
The good part of this idea is that engine builds aren't going to increase in size, but the downside is that it will only work with pr-downloader. If users download the engine manually, or if they use some other tool (such as ZK's pr-downloader), then they still need to install things themselves.

Here are some additional reading materials I found useful:
- https://itch.io/docs/itch/integrating/p ... linux.html
- https://wiki.libsdl.org/Installation (Linux and SteamOS sections)

[abma]

curl isn't linked staticly because of security updates...

openal / sdl imo can't be staticly as they often rely on installed system stuff / use different stuff in the backend.

i.e. sdl can be used for wayland or xorg. openal can be used with pulseaudio or alsa.

opengl can't be staticly linked because of drivers.

imo it comes to the point where we need a complete os for spring or a "defined environment" (linux with the mentioned libs installed)

[gajop]

Well this isn't just about static linking. Distributing shared libs with Spring is also a solution, and it might even be preferred, see: https://hg.libsdl.org/SDL/file/default/ ... -dynapi.md

To answer each particular part:

curl isn't linked staticly because of security updates...

Can't we just assume that updates will be distributed with new engine versions? Also, I think security here might be overrated. It's hard to imagine points of attack here, assuming we use safe domains. In fact, if we distributed updates ourselves, we are far more likely to ensure security updates are delivered than if we left it to the distributions. Btw, what is being done on Windows in this case?

openal / sdl imo can't be staticly as they often rely on installed system stuff / use different stuff in the backend.
i.e. sdl can be used for wayland or xorg. openal can be used with pulseaudio or alsa.

Can't we just distribute both as shared libs? I don't see the problem with that solution. The key is that users don't need to install anything themselves.

opengl can't be staticly linked because of drivers.

This one shouldn't be distributed/statically linked by Spring. Perhaps our wrapper/installers should detect if it's missing and report to users, but we shouldn't handle installation in any way.

imo it comes to the point where we need a complete os for spring or a "defined environment" (linux with the mentioned libs installed)

If we really cannot distribute shared libs/statically link stuff, then we might have to do this (it's what Steam does for many other games). I think pr-downloader would be a solution there, but I'd rather avoid going that route unless really necessary (for reasons outlined above).