FOSDEM: Linux-Gaming: Steam-Runtime in Container verpackt
Spiele bei Steam sollen problemlos laufen – mit der Abhängigkeit von antiquierten Bibliotheken unter Linux eine Herausforderung. Container können aushelfen.
Pressure-Vessel erfindet das Rad nicht neu: Die Sandboxing-Methoden für Spiele und deren Programmbibliotheken unter Steam hat Simon McVittie vom Flatpak-Tool Bubblewrap übernommen.
(Bild: FOSDEM)
Genau genommen fußt die Funktionsweise der Steam-Runtime unter Linux auf einem Hack: Spiele verlangen nach passenden Programmbibliotheken und in einigen Fällen auch nach einer ganz bestimmten, älteren oder sogar angepassten Version einer Bibliothek. Steam sowie Spiele haben deshalb die benötigten Bibliotheken mit im Gepäck.
Beim Start der Steam-Runtime macht die Umgebungsvariable LD_LIBRARY_PATH alle mitgelieferten Bibliotheken verfügbar. Die Steam-Runtime vergleicht dann die mitgelieferten Bibliotheken mit jenen des Linux-Systems und gibt den neueren Versionen den Vorzug.
Die Steam-Runtime im Dilemma
Dieser Weg funktioniert allerdings nicht immer: Einige Bibliotheken wie "libcurl" haben auf unterschiedliche Linux-Distributionen eine abweichende ABI (Binärschnittstelle). Eine ältere, mitgelieferte libcurl-Bibliothek käme aber nicht mit dem aktuellen OpenSSL des Host-Systems klar.
Es ist absehbar, dass dieses Dilemma noch größer wird und ältere Games irgendwann nicht mehr in Steam funktionieren, weil die benötigten Bibliotheken und APIs antiquiert sind. Die aktuelle Steam-Runtime stammt von 2018 und viele der mitgelieferten Bibliotheken entsprechen noch den Versionen aus Ubuntu 12.04. Aktuelle Linux-Systeme werden die verlangten Abhängigkeiten nicht immer erfüllen können. Konkrete Beispiele hierfür sind die Grafikbibliotheken von Mesa sowie 32-Bit-Versionen von Bibliotheken auf dem Host-System als Abhängigkeit.
Schon jetzt sind 32-Bit-Bibliotheken in einigen Distributionen wie Arch Linux nicht mehr in den Standardpaketquellen vorhanden, sondern wurden in ein Multilib-Repository ausgelagert. Ubuntu hat diese Bibliotheken vorerst auf den Stand von Ubuntu 18.04 eingefroren, damit zumindest jetzt noch möglichst viele 32-Bit-Spiele unter Steam funktionieren.
Container als Lösungsansatz
In einem Talk auf der FOSDEM 2020 hat Simon McVittie, der unter anderem Debian und Collabora mitentwickelt, eine mögliche Lösung des Bibliotheks-Dilemmas mit Hilfe von App-Containern präsentiert.
Nachdem es derzeit einen kaum übersehbaren Hype um Container aller Art gibt, der etliche, teils konkurrierende Ansätze hervorbringt, musste Simon McVittie das Rad nicht neu erfinden. Seine Lösung namens "Pressure-Vessel" nutzt das Tool "Bubblewrap", das vom Flatpak-Format der Gnome Foundation abstammt und Steam-Games samt benötigten Programmbibliotheken in eine eigene Sandbox isoliert. Bubblewrap wird von der Steam-Runtime als separater Prozess gestartet und stellt das Spiel im Container mit den Methoden von Flatpak bereit.
Es bleibt die Schwierigkeit, Grafiktreiber des Host-Systems aus dem Container heraus anzusprechen. Pressure-Vessel bindet dazu die Pfade zu Bibliotheken des Linux-Systems mittels Mount-Bind im Container ein. Die Zusammenstellung aller Pfade zu Bibliotheken ist mühsam, löst aber auch gleich das Problem, dass Pfade von "soname"-Bibliotheken in Binaries fest hinterlegt sind.
(Bild: FOSDEM)
Pressure-Vessel: Vor- und Nachteile
Ein netter Nebeneffekt sind eigene Home-Verzeichnisse für jedes Spiel unter Pressure-Vessel. Ein im Talk angesprochener Nachteil ist die Inkompatibilität mit der bereits existierenden, inoffiziellen Flatpak-Version von Steam. Denn verschachtelte Container funktionieren in Flatpaks nicht. Allerdings können in Zukunft mit IPC-Requests und parallel erstellten Container nachgebildet werden.
Simon McVittie veröffentlicht Pressure-Vessel und seine Fortschritte auf der Community Website SteamDB. Der kurzweilige, 20-minütige Talk zu Pressure-Vessel ist als Videostream auf der FOSDEM-Website abrufbar.
Weitere Meldungen zur FOSDEM 2020 finden Sie hier:
(ovw)
