Flatpak Steam Runtime about steam-runtime HOT 5 OPEN

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

from steam-runtime.

@kisak-valve lol whatever.

from steam-runtime.

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

from steam-runtime.

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

from steam-runtime.

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.

from steam-runtime.