Steam runtime, disabling again

slaanesh Fedora, Repositories, Steam

After re-enabling the Steam (ubuntu) runtime in package version 1.0.0.43-9, I’ve made some more tests with the runtime disabled on my systems.

The main driving factor for re-enabling the runtime was the introduction by Valve of the obsolete libudev.so.0 which has been replaced by libudev.so.1 library during the Fedora 18 release cycle.

I’ve now added back all libraries required for the client in the package prerequisites and disabled the runtime again. This time it has been disabled not through a profile script that is sourced at login time, but I’ve instead patched the main steam script in the package with a very simple patch:

--- steam.old/steam	2013-12-20 20:50:34.014610244 +0100
+++ steam/steam	2013-12-20 21:59:57.731725731 +0100
@@ -186,6 +186,17 @@
 # go to the install directory and run the client
 cp "$LAUNCHSTEAMBOOTSTRAPFILE" "$LAUNCHSTEAMDIR/bootstrap.tar.xz"
 cd "$LAUNCHSTEAMDIR"
+
+if [ ! -v STEAM_RUNTIME ]; then
+    if [ ! -h $LAUNCHSTEAMPLATFORM/libudev.so.0 ]; then
+        ln -sf /usr/lib/libudev.so.1 $LAUNCHSTEAMPLATFORM/libudev.so.0
+    fi
+    rm -fr $LAUNCHSTEAMPLATFORM/steam-runtime
+    export STEAM_RUNTIME=0
+else
+    rm -f $LAUNCHSTEAMPLATFORM/libudev.so.0
+fi
+
 if [ "`command -v tee`" != "" ]; then
 	mkdir -p --mode=777 /tmp/dumps
 	exec "$LAUNCHSTEAMDIR/$STEAMBOOTSTRAP" "$@" 2>&1 | tee "/tmp/dumps/${USER}_stdout.txt"

This checks if the STEAM_RUNTIME environment variable has been set and takes action accordingly. In the case it has not been set (the default), the script creates a symlink to the system libudev.so.1 library in the Steam folder and deletes the unpacked Ubuntu runtime. On the contrary, if you want the Ubuntu runtime enabled, by launching Steam with STEAM_RUNTIME=1 steam it will simply unpack again the runtime and restore the normal behaviour by deleting the symlink.

By using Steam’s internal variables, this also works in the following cases:

  • You’ve moved your Steam installation folder
  • You have played with the runtime enabled and are going to disable and viceversa
  • Saves me a lot of emails if I’m issuing an update to the Steam package that enables / disables the runtime; without the need for logging your user out, it works out of the box even after an update and a rerun in the same desktop session

I would say that here the “keep it simple stupid” principle applies perfectly.

The size of the Steam client has now become a little thinner again on the system on where it is installed. For comparison, here is today’s difference in size for a Steam beta client installation that uses the runtime and one that doesn’t (the SteamApps folder is the folder where applications/games are installed):

$ cd Steam
$ du -hs --exclude=SteamApps
1.4G .
$ du -hs --exclude=SteamApps --exclude=steam-runtime
1.1G .

Again, if we could run the client forcing it to avoid downloading the runtime archives as well; then the client would weigh nearly 500 mb less:

$ du -hs --exclude=SteamApps --exclude=steam-runtime*
906M

I’ve pushed this change only on the repository on this site, if it works fine and I see no objections I will push the change in RPMFusion’s repositories. The instructions in the repository page have been updated, including information on how to move your Steam installation around.

Any feedback is much appreciated!

Just in case you’re wondering, yes, I have a lot of games (~100), mostly bought off through the Humble Bundle bundles!

steam

6 thoughts to “Steam runtime, disabling again”

  1. Oh, I did not know that there are so many issues that are present only with runtime enabled, and not present with runtime disabled (like the controller or sound problems). I assumed it was just about the size. It’s a difficult question then, I agree.

    I think it’s still better to have the runtime enabled by default, because that’s what Valve offers and supports, and people are in better position when reporting problems to Valve. But it might be really beneficial to offer an easy way to switch between these two versions. I really like steam-noruntime or steam-systemdeps or similar package. That allows even not highly skilled users to easily try both approaches. That package would download the necessary dependencies and also add the correct variable to the environment (or override the launcher or something). I really like that.

    Does this mean that the ‘steam’ package would also lose dependencies on all those i686 libraries, i.e. people would need to download less packages to install steam by default? That would be a good bonus as well.

    Reply

    1. The Steam package in RPMFusion does not have a lot of requirements right now; and those are only for first start or proper operation with free drivers and can’t be reduced:

      $ rpm -qp --requires steam-1.0.0.45-1.fc20.i686.rpm 
/bin/sh
/bin/sh
/bin/sh
/usr/bin/env
alsa-lib(x86-32)
gtk2(x86-32)
libXScrnSaver(x86-32)
libpng12(x86-32)
libtxc_dxtn(x86-32)
mesa-dri-drivers(x86-32)
mesa-libGL(x86-32)
nss(x86-32)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
tar
zenity
rpmlib(PayloadIsXz) <= 5.2-1

      On the contrary, the package published here contains all the extra dependencies, which could be moved to the "extra" subpackage.

      Reply

    2. This has been done in version 1.0.0.45-6. If you don’t install steam-noruntime; you don’t have a different behaviour that what’s intended by Valve.

      Reply

  2. I think disabling the runtime causes more harm than benefit. One example I randomly stumbled upon is here:
    https://github.com/ValveSoftware/steam-for-linux/issues/2980
    and after a short search:
    https://github.com/ValveSoftware/steam-for-linux/issues/2718
    https://github.com/ValveSoftware/steam-for-linux/issues/2740

    I think this is not KISS principle, it’s lets-have-complications-just-to-save-some-space principle. I’d advise to keep the runtime enabled. Most gamers don’t care about a few hundreds MB that can be saved – most of the games are much larger than that! Steam runtime size is negligible compared to that. However, they care about their games functioning properly.

    You can’t possibly check all games all the time. Also, symlinking different library versions (libudev.so.0 to libudev.so.1) asks for troubles. And last but not least, months might pass before somebody tells you about a problem with a particular game which is caused by disabled runtime. In the mean time, hundreds or general users won’t be able to run that game. Not a good experience.

    Experienced users can always disable steam runtime on their own. And those are the users who will be able to deal with the consequences (or revert back to a default, safe state).

    Thanks for working on this.

    Reply

    1. First of all thanks for feedback đŸ™‚

      Actually I stumbled on another SDL problem while testing very old Steam games with the runtime disabled; this was solved by putting additional dependencies in the steam package. I agree that in most cases it doesn’t matter if 500 mb are stolen with duplicated libraries on a gaming PC and that I might run into obscure issues while trying to enforce the use of system libraries to everyone, especially when years pass by and distributions change.

      Regarding the 3 issues you posted:

      • First one indeed, was when the steam package in RPMFusion had the runtime disabled (should be fixed now, though).
      • Second one is about a use which has a missing library in the Steam client itself and actually disabling the runtime fixed the game for him.
      • Third case is about a use which was missing Steam client libraries, not runtime related.

      On my particular case, for the system libraries crusade:

      • I’m not able to have my controller (xinput) recognized properly by Steam without using the Fedora system libudev library.
      • Have cracking sound in a couple of games.
      • Have artifacts on the screen when launching Big Picture Mode with proprietary Nvidia drivers.

      There some other reports, like ALSA libraries in the runtime not supporting 7.1 speakers (!!) but I’m not able to test.

      Having said all of this, I agree that I can’t solve all problems, issues should be reported upstream and experienced users are probably doing this on their own. I’m thinking about two options:

      • Leaving the Steam package as is in RPMFusion (with the runtime enabled, everything as Valve’s default) and providing a sub-package for Steam (something like steam-noruntime) that disables the runtime and pulls in the additional dependencies.
      • Leave a separate package here in my repository with the Runtime disabled.

      What do you think?

      Reply

Leave a Reply