Why is SDL2.0 held privately [sandboxed] on Debian

[Illasera]

I have downloaded the steam package from Debian Jessie testing repo.

A quick Dependency scan shows this :
/home/my_username/.steam/ubuntu12_32/libSDL2-2.0.so.0
SDL2 loaded in private (as in private memory), Which is a damn shame because i do have other softwares that are using SDL2 (same version), so why loading it more than once?
As well as the other libraries that steam uses being installed/used in my home folder in somewhat of a sandbox mode.

I am aware of the fact that steam for linux started in ubuntu environment, My question is, why is it still the case here? Even if i downloaded the "installer" from the Debian repo?

[Letalis Sonus]

It's simple: to prevent incompatibilities. There have been several games in the past that had problems with differences in the SDL libraries provided by the system. Additionally it might as well provide a more up-to-date version withouth breaking other things.

[R3450N]

This is because of inconsistency issues across Linux distros. In order to ensure that the end-product works it's linked with a localised version of the relevant libraries within the binaries itself. Because there's no single package manager on Linux to manage everything unilaterally something like this has to be done just in case the SDL version held by the distro is incompatible with the one the end-product uses. Just my token here.

[Illasera]

As mentioned before, I wrote that i downloaded steam from the DEBIAN testing repo
of course there is inconsistency issues across Linux distros, That's why the distro owners usually try to sort them out.

As far as the previous argument, That there are different versions of SDL Library and they may have compatibilities issues, Yes, usually SDL 1.x WITH SDL 2.x (SDL 2.x is not backward compatible with 1.x However, i was talking about SDL2.x on its own, Steam uses the same version it seems as the one in debian-sid(unstable).

[JJ]

The reason is: non-free software.
The "steam-runtime" environment is managed by Valve, they know what they are linking their programs/games to.
If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.

Normally, package maintainers would update dependent programs, but Valve's binaries are closed-source so nobody else is able to relink against updated libraries.

[Illasera]

Publicado originalmente por TheJJ:

The reason is: non-free software.
The "steam-runtime" environment is managed by Valve, they know what they are linking their programs/games to.
If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.

Normally, package maintainers would update dependent programs, but Valve's binaries are closed-source so nobody else is able to relink against updated libraries.

THANK YOU, that make sense :) at least now i know

[Letalis Sonus]

Publicado originalmente por TheJJ:

If they used the distro's libraries, Valve would have to react and relink when the distro releases updates.

Not really. Generally the involved libraries are all developed in a way that makes them upwards compatible, old interfaces are kept until enough obsolete stuff has been collected for a new large major release that will drop them, which will end up in a different file that can be installed side by side with the old version (e.g. like GTK2 and GTK3), the whole library version naming is pretty much standardised and consistent among the different distros, at least concering those core libraries. The libstdc++ is a special case and a lot more touchy about that, but it still follows the same pattern.

The symbols are remaining the same, there's no problem with replacing some libraries with different versions without any need to relink anything at all - you'd rather need to entirely recompile it if you need to take action, anyway. The small changes that every distributor applies to their version are much more problematic, especially if they are using different compile-time options resulting in different feature sets.