Advice for downstream distributions re decoder libs

[lazka]

We got a request that our downstream package should be built with the new dr stb internal decoders instead of the external libraries such as libvorbis/libflac/mpg123.

What's the recommended way to build sdl_mixer for downstream distributions?

thanks!

[slouken]

Typically games like to reduce dependencies on external libraries, so SDL libraries are built with that in mind. If you build with the default configure flags, you'll get a library which uses the built-in decoders for Vorbis, MP3, and FLAC, and dynamically loads libraries for other codecs if they are available, which is how the macOS and Windows official packages are built.

That said, distributions tend to build with all available codecs and hard-link dependencies so programs are guaranteed that every codec is available, since they don't know what games will need at runtime.

I would recommend building with all codecs, using the built-in decoders as much as possible to minimize system dependencies. This will give you the best of both worlds. We recently updated our versioning and release processes to more easily release updates if there are security vulnerabilities or other critical fixes needed by downstream distributions.

@smcv may have more insight, as he is the Debian SDL package maintainer.

[smcv]

It really depends how your downstream distribution works, whether copying out binary libraries and using them outside your dependency framework is a supported use-case for you, and what your priorities are.

In Linux distributions, the cost of a hard dependency on a system library (linking with -lvorbis or equivalent, as opposed to letting SDL dynamically load it at runtime) is low, because we have packaging systems that keep track of these things and won't let you install a broken or incomplete configuration - and in fact we actively prefer to use hard dependencies, because our packaging systems can automatically detect hard dependencies between libraries and generate the right packaging-level dependency relationships, but we can't automatically detect weak dependencies via dynamic loading.

In ad-hoc binary builds designed to be copied into games as-is, I can see that being self-contained as much as possible, and having weak dependencies where it isn't feasible to be self-contained, would be more appealing.

Linux distributions usually prefer to use external libraries like libmpg123 and libvorbis rather than "lightweight" built-in/bundled code like the STB decoders, for a few reasons:

• if there's a security vulnerability or another serious bug, we can often fix the bug for all library users (ffmpeg, gstreamer, SDL_mixer, etc.) by just rebuilding the external library, whereas if there's a serious bug in a bundled decoder we have to identify and rebuild everything that has a bundled copy;
• a typical installed system probably has most of the external libraries already, pulled in by ffmpeg or gstreamer or some similar framework, so having SDL_mixer also depend on them doesn't take up much more disk space or cause much more work for us;
• the older external libraries often have a history of effort going into automated tests, fuzzing and security auditing, a maintainer team we already interact with, etc., so we start with a higher level of confidence about their quality;
• there's no such thing as a free lunch, so smaller implementations usually have to make some sacrifices to achieve small code size, whether that's in speed, memory-efficiency, missing features, robustness against corrupted inputs, security (robustness against actively malicious inputs), or some other factor they're willing to sacrifice for size

Obviously a lot of those reasons become less important or vanish altogether if you're shipping a library that is solely for use by one game or one framework, rather than sharing a library like libmpg123 or libvorbis with an entire OS distribution.

The priorities also shift depending on whether you're a rolling-release distribution like Arch or Gentoo, or a stable-release distribution like Debian or RHEL. In a rolling release, if SDL_mixer makes a new release to fix a security issue in a bundled decoder, you can integrate it through your normal update procedure, but in a stable-release distribution that doesn't accept changes that come with a regression risk, someone will likely have to backport the change to the version that the stable release happens to have (which makes it a lot more time-expensive to track down and update bundled dependencies, and a lot more appealing to be able to do a single update to something like libmpg123 or libvorbis and know that it will fix the vulnerability for all the higher-level frameworks that use it).