Bug#916303: steam: installs to ~/.steam, which is not as intended by upstream

[Simon McVittie]

Package: steam
Version: 1.0.0.56-1
Severity: important
Tags: patch

According to Valve developers, the Steam client is meant to support
multiple parallel installations, with $XDG_DATA_HOME/Steam as the path
that is normally used. On Linux, ~/.steam/steam is meant to be a symbolic
link to the most recently run installation root for production versions
of the Steam client (there can also be a parallel ~/.steam/steambeta
for internal beta-test versions, which you can see referenced in the
bin_steam.sh script), which allows the Steam client and the Steamworks API
to find the Steam installation root even if the XDG_DATA_HOME environment
variable has changed since installation. Users can also switch between
multiple parallel installations by running /path/to/installation/steam.sh,
which will update the symbolic links.

The steam package in Debian has traditionally unpacked the Steam
bootstrapper directly into ~/.steam, which gives that directory a dual
role: the installation root, and also the symlink farm.  Unfortunately,
a bootstrapped installation root will contain a ./steam directory,
which collides with the ~/.steam/steam symbolic link, preventing its
creation. Components of the Steam client end up unpredictably installed
into either ~/.steam or ~/.steam/steam, depending on the exact path
they open (writes via ~/.steam/steam end up in the subdirectory,
but writes via ~/.steam/root do not, even though in Valve's Steam client
package, both are normally meant to be symlinks to ~/.local/share/Steam).

For example, my ~/.steam directory on one Debian machine has most games
and mods in ~/.steam/steam/SteamApps, but one mod in ~/.steam/steamapps
instead. (I suspect that single mod might actually not work at all.)

We can't easily disentangle this for existing installations, but for
new installations we can reduce confusion by behaving the way
upstream intended.

The attached patches also make the shell script more robust by quoting
variables more defensively.

I've tested this against an existing Debian Steam installation in ~/.steam
(layout is unchanged) and in a new installation (the client ends up
installed in ~/.local/share/Steam as intended, with symlinks in ~/.steam).

    smcv