Make SrtSystemInfo OS info fall back to lsb_release
User story
s-r-t should be able to reliably tell which OS it is running on.
Description
The current OS info implementation parses os-release
. However this file is not guaranteed to be available.
For this reason we could provide an additional fallback with the common lsb_release
too.
The details of the fields are:
ID: fall back to the result of taking lsb_release -si, normalized by flattening it to lower-case and replacing everything except ".", "_" and "-" with "_"
ID_LIKE: consider adding hard-coded values for well-known OSs like Ubuntu? or leave it empty
VERSION_ID: fall back to lsb_release -sr with the same normalization as ID
VERSION_CODENAME: fall back to lsb_release -sc
NAME: fall back to lsb_release -si
PRETTY_NAME: fall back to lsb_release -sd
Additional info from the initial internal task:
Implementation suggestions:
- Read /usr/lib/os-release and /etc/os-release first, and only run lsb_release if neither of those exists.
- Note that there is no official API for lsb_release based on reading files (reading /etc/lsb_release is tempting but wrong). The only API is to run a command and read the output.
- I've described things in terms of individual commands like lsb_release -sd, but the LSB spec does document the output format, so what we should probably actually do is to run lsb_release -a and parse it.
- Automated test: when using a SRT_TEST_SYSROOT, we can prepend ${SRT_TEST_SYSROOT}/bin to PATH, and provide a mock lsb_release there. (It can be a simple shell script using printf or even cat <<'EOF', it doesn't need to be C code.)
If the entire Steam client is running in a container (like the Flatpak package on Flathub) then the OS information that is reported will be facts about the container, rather than than facts about the host OS. I think that's what we want: in that situation, anything in the Steam environment that isn't overridden by a LD_LIBRARY_PATH will be from the container, and effectively, the container is acting as the host OS.
If we need information about the host OS, then as a future enhancement we could perhaps make a way to instantiate a second SrtSystemInfo that looks at /run/host/usr/lib/os-release, and the same accessors on that object would tell us about the OS that is hosting our container.
Deadline
Low priority enhancement
Acceptance
-
Fall back to lsb_release
as described above -
Automated tests -
Code review -
Include in a release
Out of scope
- Taking action based on the OS we discovered
- Enumerating some finite number of known OSs (Ubuntu, Arch, SteamOS, etc.)
- Looking at the os-release from outside the container, if we are in a container
- Modifying the Steam client so that it uses this API instead of having its own implementation
This was previously tracked internally as T16069.