Skip to content
Snippets Groups Projects
Simon McVittie's avatar
Simon McVittie authored
At the moment we deploy the runtime from a giant tarball to avoid Steam
downloader limitations, but that leads to a noticeable delay the first
time we launch a game after a new runtime version has been downloaded.

Now that the Steam download mechanism can deal better with larger
numbers of smaller files, we're considering returning to the original
design where the runtime depot contains unpacked files. However, the
Steam download mechanism doesn't preserve permissions, modification
times, or filenames that differ only by case, and has not always
preserved empty directories, so we need a way to deal with all of
those things.

By reading a manifest written in a subset of the BSD mtree(5) format,
we can create directories and symlinks, and set permissions modification
times on regular files. As a bonus, it's actually slightly faster to
duplicate a runtime with hard-links (--copy-runtime mode) by reading the
manifest than by reading the actual directory tree, because the manifest
is more likely to be contiguous on disk.

In principle the mtree(5) manifest could also be used to validate that
the runtime content has not become corrupted by checking files against
their sha256sums. This isn't implemented here (and it would have to be
done only on demand rather than routinely, because it would be slow),
but the parser does at least read the sha256.

In the tests, we now need to remove the mtree manifest when copying
and editing a runtime. When we edit a runtime in-place, it no longer
conforms to the manifest, so this can't necesarily be expected to work.

Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
799b7931
History

steam-runtime-tools — Steam Runtime integration for the Steam client

The steam-runtime-tools library provides low-level Unix-specific tools and functionality for the Steam client, including the pressure-vessel tool that runs Steam games in containers.

To support multiple architectures (currently only i386 and x86_64 are supported), you will need to build it once for each architecture and install at least the helper tools in /usr/libexec/steam-runtime-tools-0 (the libsteam-runtime-tools-0-helpers package) for every architecture in parallel.

The helper tools are located relative to the shared library, so it's OK to bundle steam-runtime-tools alongside some other stack in this layout:

anything/
    lib/
        x86_64-linux-gnu/
            libsteam-runtime-tools-0.so.0
    libexec/
        steam-runtime-tools-0/
            i386-linux-gnu-*
            x86_64-linux-gnu-*

as long as the program that is linked to libsteam-runtime-tools-0.so.0 can find it (via a RPATH or RUNPATH or by setting the LD_LIBRARY_PATH environment variable).

pressure-vessel — putting Steam in containers

The pressure-vessel/ subdirectory of this project contains the pressure-vessel utilities, which are used by Steam's Steam Linux Runtime compatibility tool to run games in individual game-specific containers. For background on pressure-vessel and SteamLinuxRuntime, please see: