Some applications such as Natron need access to MIT-SHM or other
shared memory mechanisms. Unsharing the pid namespace
breaks the ability for application to reference shared memory.
The desktop application and the absoloute path work fine.
But consider desktop environments such as KDE where, in the application
menu, one can right click entries and pin them to widgets/panels, add
them to the desktop, etc.
Doing so effectively means copying
/run/current-system/sw/share/applications/steam.desktop to
~/.local/share/plasma_icons/ or ~/Desktop/, i.e. managed stated gets
duplicated outside the nix scope.
The problem here is that steam.desktop hardcodes
Exec=/nix/store/<derivation hash>-steam/bin/steam %U
this means such copies will point at wrong/outdated derivations once
the steam package changes, i.e. widgets/panels/desktop icons will no
longer work and must be recreated.
Therefore replace the absoloute path with a $PATH lookup to allow "safe"
copying; this isn't optimal but other applications such Firefox and
Thunderbrid currently behave the same way ($PATH lookup in their
.desktop file).
In my previous commit (593c28b) I used the wrong upstream artifact for
the runtime. After reading the documentation in the
ValveSoftware/steam-runtime repo, I now know that the steam-runtime
tarball is what I actually wanted.
I also used 'diff' to compare the various artifacts with the old runtime
this package used before, and the steam-runtime one is certainly the
closest.
Most importantly, switching to the right steam-runtime package
reportedly fixes issues for other users (fixes#90229).
This also entirely removes the amd64/i386 split from runtime.nix because
the upstream package bundles both together, and if that's how upstream
wants to distribute this, it seems best to follow their lead.
Valve has started releasing tarballs of the steam runtime. It seems a
lot easier to download and extract a single tarball than to download a
buncha debs, extract them, and splat em around a bit.
Let's just use the runtime they build. It's a buncha random binary
packages anyway.
Also, the download url for their debs broke, so there's that too.
Noticed that the setup.sh for steam was trying to call the file command.
I'm not sure what the ramifications are for these missing,
but some steam features are quietly disabled when they
don't follow happy paths.
Naive concatenation of $LD_LIBRARY_PATH can result in an empty
colon-delimited segment; this tells glibc to load libraries from the
current directory, which is definitely wrong, and may be a security
vulnerability if the current directory is untrusted. (See #67234, for
example.) Fix this throughout the tree.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
