Commit 3501b9cd authored by Simon McVittie's avatar Simon McVittie
Browse files

README: Say how this interacts with other important packages


Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
parent ee0c25a0
......@@ -13,6 +13,57 @@ incompatible with the older Steam Runtime 1 'scout'.
See <https://github.com/ValveSoftware/steam-runtime> for more information
about the Steam Runtime.
How this fits into the overall Steam Runtime project
----------------------------------------------------
1. Build .deb packages for the content of the Steam Runtime.
`steamrt` is one of these packages.
2. Put together the .deb packages into a Flatpak-style container runtime.
This step is done by
[flatdeb-steam](https://gitlab.steamos.cloud/steamrt/flatdeb-steam),
but the choice of the actual packages to include is mostly delegated to
`steamrt`.
3. Turn the container runtime into a Steampipe depot. This is controlled by
[steamlinuxruntime](https://gitlab.steamos.cloud/steamrt/steamlinuxruntime).
Why is this Steam Runtime 2 when heavy was released first?
----------------------------------------------------------
Steam Runtime 2 is older than heavy, but heavy has an older base OS
and was released to the public first. By the time heavy started, Steam
Runtime 2 was already under development, so heavy is considered to be
Steam Runtime 1½.
Steam Runtime 2 is also only the second runtime (after scout) that is
complete enough to run games, which was the Steam Runtime's original
purpose. Steam Runtime 1½ consists of enough to compile and run
`steamwebhelper` and no more, so we consider it to only be half a runtime.
Why does soldier require container technology?
----------------------------------------------
The traditional `LD_LIBRARY_PATH` runtime only works because we're lucky,
and because modern host OSs are strictly newer than it.
Making a `LD_LIBRARY_PATH`-based runtime reliable is difficult, especially
if you want it to be runnable on host OSs that have some packages that
are older than the runtime.
Some libraries cannot be bundled in a `LD_LIBRARY_PATH` for technical
reasons (mainly glibc and graphics drivers). A `LD_LIBRARY_PATH` runtime
needs to get these from the host system, and they need to be at least the
version it was compiled against. This is fine for scout, which is very
old, but would not be OK for a Debian 10-based runtime, which wouldn't work
on (for example) Ubuntu 18.04.
Some libraries *can* be bundled, but need to be patched to search for
plugins in different places (either inside the runtime itself, or in
multiple distro-dependent places), which is not really sustainable.
Using namespace (container) technology to replace `/usr` with the
runtime's libraries sidesteps both these problems.
Where can I get it?
-------------------
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment