As of snapd 2.28 - "base" snaps are a new thing. After talking with the +Snapcraft team we've determined the best route for building a prototype snap based on Solus.

That snap, as some people have already guessed as much, will be the linux-steam-integration project, using a strict-mode LSI intercept module. We can also make various tweaks on top of that runtime to enforce ABI compatibility where it might be missing.

This guy: https://github.com/solus-project/linux-steam-integration

Why You Do This??

It's time to relieve the pressure on distributions for supporting gaming, by doing so through a single point of entry. A snapped LSI will ensure that the Steam/LSI combo would work identically on every distribution, *even if they don't support multilib*. It also ensures we can provide a "perfect" runtime, but ensure its up to date, optimised, and configured explicitly to support LSI & Steam.

But that one time with flatpak

Yep, we did consider this a long time ago with Flatpak. However, it is dramatically simpler to do this using Snaps, one of the chief reasons being the ease of driver integration (reinventing the various freedesktop entry points to satisfy installation of non-host drivers for NVIDIA users just to have a Solus based runtime and avoid Yocto in its entirety)

When will it be done

Not overnight! We're gonna get new snapd into Solus, which supports the new "pack" command, and will allow us to quickly "snap up" the base image produced from our own tooling. I'm going to be working on this over the next few weeks, and start prodding at all the various issues.

TLDR: Single Steam/LSI image that takes all of the Solus gaming/Steam work, and provides it for everyone, on any distro.

Note we're also building tooling in parallel which will allow us to easily debug the runtime, to ensure ABI compatibility is maintained for Steam itself and the games. One such tool is being developed here: https://github.com/ikeydoherty/runtime-abi-check