Linuxでどうやってゲームバイナリを配布するか

SDLのMLで微妙に興味深い話題が進行している。要するにゲームのバイナリを各種Linuxディストリビューションに対してどうやって配布するかという問題で、Ryanの投稿でほぼ結論が出ている:

> Yes I know that the ideal thing would be to make packages for each
> distro

Nope, never do this.

> (even better, let the maintainers do it,

Nope, never do this either*.

要するに、Steam runtimeにリンクし、必要ならばSteam Runtime(の一部)ごと配布せよというもの。一般にこの手のシチュエーションでは静的リンクが勧められているが、現状は動的リンクでknown-goodなライブラリを使えということになる。
Steam RuntimeはSteam自身ではなく、単にゲームが動作するために必要なライブラリを集めたビルド環境と言える。ValveはこれをGitHub上で配布している:

パッケージにはSDL2やOpenAL Softが含まれているが、Gstreamerは0.1系である等微妙にバージョンが古いものもある。
Steam RuntimeはSteamをインストールすると自動的にインストール/保守されるが、通常のLinuxのパッケージマネージャはこれをアップデートできない。各ディストリビューションはそれぞれのSteam対策を持っている:

SteamなしでSteam Runtimeを使う方法も編み出されている:

静的リンクがダメな理由

理由は上記のMLでもいろいろ挙がっているが、要するにOpenGLドライバが動的リンクのlibcに依存していることが最も単純な理由付けと言える。我々はOpenGLドライバを再配布するわけにはいかないので、自ずとOpenGLドライバの動作環境がゲームの動作環境を最も制約することになる。
KhronosはそもそもOpenGLの公式ヘッダを配布しており、OpenGL ABIに関してはKhronosヘッダのものが事実上の標準と言える。このようにABI標準が確立しているのにも関わらず、静的リンクのプログラムが配布できないのは、実際のOpenGLドライバが.soで配布されており.soのローダがlibcを含めたランタイムライブラリに依存していることに起因する。そして、これらにリンクするためにはlibcのABIに依存するということになってしまっている。
(この理由付けによりゲームアプリケーションが例えばDockerのようなコンテナモデルにもよく適合しないと言える)
ちなみに、ABIを含めたLinux上のアプリケーションの業界標準であるLSB(Linux Standard Base)仕様では、仕様に無いライブラリは静的リンクするか一緒に配布しろということになっている:

If an application cannot limit itself to the interfaces of the libraries listed above, then -- to minimize runtime errors -- the application must either bundle the non-specified library as part of the application, or it must statically link the library to the application.

LSBはlibGLを標準に含んでいるが、では、LSBに乗っ取ってゲームを配布しているような例は実際にあるのだろうか。。LSBは現在策定中のLSB5でようやくOpenGL2になったところなので、まだまだ先は長いとしか言いようがない。