Category: Fedora

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!

Due to some issues with libraries in an upcoming Steam client update, I’m forced to re-enable the Steam runtime (Ubuntu libraries) in Fedora’s Steam package. This means that all dependencies are no longer needed but the size of the Steam client can get ridiculously high on the system on where it is installed. For comparison, see the difference in size for an installation that uses the Steam runtime and one that doesn’t (the SteamApps folder is the folder where applications/games are installed):

$ du -hs --exclude=SteamApps
1.3G
$ du -hs --exclude=SteamApps --exclude=steam-runtime
992M

If we could run it without the Steam runtime enabled and also avoid downloading the runtime archives; then the client would weight nearly 500 mb less:

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

Let’s hope that in the future Valve will not mandate the use of Ubuntu libraries for long and will standardize on a specific set of common libraries.

I’ve updated the repository page with updated instruction and pushed updated packages both to the repository and in RPMFusion. Starting from package steam-1.0.0.43-9 the Steam runtime is left at the default value (enabled).

The Steam package has been under review in RPMFusion for the latest 20 days:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2979

It has now got a reviewer; so with a bit of hope the package could be finally merged into RPMFusion! At the moment, the package in my repository is exactly the same as the last one posted in the review.

I’ve just updated the Steam package to the latest release (1.0.0.43) and in addition to the Steam controller support there are now udev rules for the Oculus Rift! This is the changelog content:

$ cat /usr/share/doc/steam-1.0.0.43/changelog | head -5
steam (1.0.0.43) precise; urgency=low

  * Update udev rules to support front panel and Oculus Rift
  * Demote jockey-common dependency to Recommends

And this is the content of the UDEV rules’ file:

$ cat /usr/lib/udev/rules.d/99-steam-controller-perms.rules
#USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="c251", ATTRS{idProduct}=="2202", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="2202", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1101", MODE="0666"
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", ATTRS{idProduct}=="1051", MODE="0666"
# Oculus HID Sensor naming and permissioning
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="2833", MODE="0666"

Would you consider buying an Oculus if Steam games start to support it?