launch-options: Improve handling of steam-launch-wrapper and reaper
- Aug 09, 2024
-
-
Simon McVittie authored
If we're using a pressure-vessel-based container framework, it's potentially still desirable to switch to a LDLP runtime under test. This affects the execution environment for the reaper, the steam-launch-wrapper, and pressure-vessel-unruntime (although we expect that its effect is undone by pressure-vessel-unruntime). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's reasonable for steam-launch-wrapper to want to adjust the PATH or LD_LIBRARY_PATH that were provided by the LDLP runtime, for example for steamrt/tasks#489. That won't work if we immediately overwrite them by switching into a different LDLP runtime. This also means that while testing a non-default LDLP runtime, we'll use the runtime under test (and not the LDLP runtime that Steam is using, if different) to run the steam-launch-wrapper and reaper. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
They were already treated as functionally equivalent. Formalize that by turning them into an ordered list of essentially arbitrary "adverb" wrappers. The functional change here is that previously, we would only have recognised the nesting used in practice by Steam, where `%command%` expands to: reaper ... -- steam-launch-wrapper ... -- [compat-tools --] game but now we recognise, and preserve, the opposite order, which is preferable if steam-launch-wrapper starts putting its contents into a systemd cgroup: steam-launch-wrapper ... -- reaper ... -- [compat-tools --] game steamrt/tasks#266 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-