Creating this post purely to help track the progress of moving linux-steam-integration (and thus, steam) into a snap based on a Solus derived runtime. Figured it’d be a bit of fun to track it. 
Le relevant project: https://github.com/solus-project/linux-steam-integration
So, without further ado, let’s get this road on the show now that Solus has snapd 2.29.2 and I can actually use snap pack.
Started new project on GitHub to contain the entirety of the runtime work:
Update: Now got a very basic Solus core snap which has a default entry point for /bin/bash so I can debug it, and snapd is able to correctly mount and use it. Next steps, adding the rest of the runtime, chucking in Steam and making sure it all works, then cleaning it up
Very close…
Had to make some ugly workarounds in my script to rename libdirs, which will require upstream confinement patches to understand lib64 + lib dirs, and some minor changes to allow supporting bash (not dash) with apparmor confinement in the base snap, but pretty trivial stuff so far.
Seriously, You are awesome!! following since your Solus Project!
Created a tracking issue over @ LSI repo with some of the issues I’ve encountered, basically LSI is kinda dumb and doesn’t know how/where to deal with non-system-steam:
All boils down to teaching it about SNAP environmental variables, shouldn’t be too difficult.
Thanks bud! 
Due to some uh, potholes, I’m not focusing on confinement now. We’ll do this when the proof of concept actually fully works.
Speaking of which …
you spelt “plot holes” wrong :-p
I always like pointing plot holes out to everyone else to ruin their enjoyment… teehee
Update: I had to perform some local hackery to snapd to support biarch drivers, but I’m hopeful it can be upstreamed.
This is letting me currently use 32-bit + 64-bit NVIDIA GL within the snap
Networking appears to be a bust at the moment, and LSI is currently buggering with /var/lib/snapd/lib/gl expections, so we need to actually build those redirects straight into liblsi-intercept.so. This is good progress though I think. In my local implementation I’ve opted to have the confinement mkdir a 32 subdir under the rootfs /var/lib/snapd/lib/gl and attempt to populate the symlink farm with /usr/lib32 libraries, and that’s working quite nicely.
What if we create snap package of nvidia driver which you can link to steam? and other apps? As you are saying 32-bit + 64-bit NVIDIA GL within the snap, it will increase the size of the snap even for non-nvidia binary driver user? Like flatpak have.
Correct me if i am wrong, i don’t really know how snap interact with gpu drivers.
No this is still using the host drivers, I’m extending the biarch mechanism that already exists to make the 32-bit variant of the drivers available too. It’s not actually shipped in the snap
But the real problem will be, We can’t select the path, like i want to install game in other drive or path, snap doesn’t allow that, according to my knowledge.
It will if I set home + removable-media plugs.
Best of luck on your Quest!!! Take my Power!!! 
Edited: Let me know if you need any help, like testing stuff, and other thing.
OK I just taught LSI how to handle NVIDIA and libGL redirections - here is a screenshot of LSI’d Steam (using liblsi-intercept.so and liblsi-redirect.so) with the solus-runtime-gaming !
Still need to teach the main shim to respect $SNAP environmental variable so it can set up the libraries without intervention, and I need to fix minor cruft in the runtime with broken SSL certs, but damn if we’re not close.
I might as well install steam again!
Soon!
Just got done adding snapd support to LSI so that it respects $SNAP and sets up the environment without requiring any wrapper scripts. The settings UI still needs it but that’s fine for now.
