Flatpak Steam Runtime

[computerquip]

This has the pros of:

1. Sandboxing,
2. Sane environment for library dependencies.
3. A catalyst to place the Steam runtime in so there is no need for a mountain of LD_LIBRARY_PATH and LD_PRELOAD hacks. This will inherently remove the libstdc++ conflict and other problems.

This has the cons of:

1. Requiring the application (game developers) to support Flatpak.

Is it viable or worth it?

[adityashah1212]

I like this but Nvidia libraries shipped with proprietary drivers still don't work with flatpaks. Have a look here

[h1z1]

@kisak-valve lol whatever.

[jjardon]

A flatpak for steam already exist here: https://github.com/flathub/com.valvesoftware.Steam

[nanonyme]

For what I've seen as one of the maintainers of said repo, I'm no longer confident it makes sense to do it as described above. This is just my personal opinion. The setup where you have

1) OS (Flatpak runtime) 2) Steam runtime 3) Game

does have distinct advantages. It's really painful to support games with a single runtime if your maintenance span is decades. With a multi-layer solution layer 1 can be updated more freely while layer 2 should be strictly versioned, conservatively changed and provide a platform for a generation of games. In this vision you could have multiple layer 2 runtimes and they could be installed as needed. Current Steam runtime maintenance model is based on brief glancing over issues already showing scalability issues. The change from Freedesktop runtime 1.6 to 18.08 shows layer 1 might face drastic changes

[nanonyme]

There's also some merits to the idea or some of its variants. Basically currently one issue with Steam is some games ignore the LD_LIBRARY_PATH given by Steam and just simply break if system doesn't have the right libraries. With current Steam Flatpak we control system dynamic linker path and might be capable of side-stepping a lot of the issues of current day Steam if we had Steam runtime in predetermined global path when ldconfig is run. It might mean we might need to manage updating it outside the context of Steam though. I'd say at this point though that I consider a Steam runtime as a Flatpak runtime extension that can be used in addition to normal Freedesktop Runtime a better option than making Steam runtime a regular Flatpak Runtime. Steam runtime is designed to work in cooperation with a host OS and it might not make sense to change this so the solution won't diverge too much from regular Steam deployment method. Pinning libraries is still an open question but there's some ideas handling that as well.