So you can download Steam for Linux now!. Or at least Ubuntu. The 1.0.0.22-version package needs a bit of tweaking to make it installable on Debian. There's a good writeup of some of the issues in this blog post (more recent packages seem to have much more simple dependencies). I run amd64 with multiarch enabled for i386. I chose to update my libc to the version in experimental rather than embed a newer version in a private steam directory. The remaining issues are mostly package version differences between Ubuntu (who seem to be very epoch-happy, I guess they've made a lot more packaging mistakes) and Debian.

I wrote the following script to do the work. It takes two arguments: the original steam .deb and then the output filename to write a modified .deb to. Feel free to try it.

#!/bin/sh
set -u
set -e
[ $# -eq 2 ] || { echo "$0 <in-deb> <out-deb>" >&2; exit 1; }
wd=$(mktemp -td $0.XXXXXX)
trap "rm -r '$wd'" INT QUIT EXIT
dpkg-deb -x "$1" "$wd/steam"
dpkg-deb -e "$1" "$wd/steam/DEBIAN"
sed -i  -e 's/\(libpulse0 (>= \)1:/\1/' -e '# remove ubuntu epoch' \
    -e 's/^\(Version:.*\)$/\1+jmtd/' \
    -e 's/xterm | gnome-terminal,//' -e '# seems to be an apt bug here' \
    -e 's/\(multiarch-support (>= 2.15\)[^)]*/\1/' -e '# remove ubuntu epoch' \
    "$wd/steam/DEBIAN/control"
mv "$wd/steam/usr/bin/steamdeps" "$wd/steam/usr/bin/steamdeps.orig"
ln -s "/bin/true" "$wd/steam/usr/bin/steamdeps"
fakeroot dpkg-deb -b "$wd/steam" "$2"

The most interesting (to me, anyway) package foible was the dependency on xterm | gnome-terminal. I have both installed, but neither for i386. Of course, steam doesn't need a 32 bit terminal emulator, it can spawn the 64 bit one perfectly well. It turns out that you can't express such a dependency at the moment. Even changing that to a virtual package x-terminal-emulator didn't work: aptitude still wanted to pull in a 32 bit match and all the supporting libraries. For this package I just delete the dependency outright.


Comments

The gnome-terminal problem would be Debian bug http://bugs.debian.org/698957.
Comment by Guillem Jover
Well, thanks Ubuntu for the introduction of utterly needless incompatibilities with Debian. On of the advantages of the DEB package format was that we did not have something similar to RPM hell - that is, as long as everybody really cared.
Comment by Fabian
License changed to allow redistribution. Time to upload to non-free? :p
Comment by Jo Shields
Unfortunately, epoch mistakes only need to happen once, and one is stuck with them forever. Ubuntu developers get shouted at a lot, for bumping epochs, but we can't undo it, all we can do is encourage Debian to bump the epoch too... :(
Comment by Stefano Rivera

Modifying the steam's DEBIAN/control is not needed anymore since 1.0.0.24 But maybe you could just make a package that depend on steam and just divert /usr/bin/steamdeps with a link or script to /bin/true (or log what it wants, exclude multiarch-support and jockey-common?)

Great! thanks for the info

some selinux rules to isolate it next ;)

Comment by aL

"Very" is a bit strong. We're very conservative about adding epochs for any packages we share with Debian, for good reason. There are 18 source packages with newer epochs in Ubuntu than Debian; 5 with newer epochs in Debian than in Ubuntu; and if I've got my search expression right then there are 881 source packages with any epochs at all in Debian. No doubt this points to the odd mistake, but it hardly seems to equate to Ubuntu having made a lot more packaging mistakes.

On the specific examples you gave, it's true that libpulse0 has an epoch, which was due to uploading a test version of pulseaudio by mistake. (And I think introducing an epoch there was an error; a "+really"-type version would have allowed us to get rid of it eventually.) However, you're mistaken in commenting that multiarch-support has an epoch, and your sed expression doesn't remove one; rather, it removes the revision part of the version.

Comment by Colin Watson

Also, two other things:

  • 'dpkg-deb -R' would abbreviate your script
  • I'm surprised that the xterm dependency was a problem, since xterm is declared as "Multi-Arch: foreign" (thanks to a change made by Ubuntu developers), which should have been enough. Is it possible that you have a version of xterm earlier than 278-3 installed?
Comment by Colin Watson

@Colin: Thanks for your comments. Perhaps "very" is too strong indeed. I wasn't trying to be particularly perjorative, either. I have hit this problem somewhere else (nautilus, I think) and the most pragmatic solution IMHO would be for Debian to bump epochs up to match.

Thanks for the dpkg-deb -R tip!

jon

@Alam Arias: Thanks, you're right, it looks like the dependencies of 1.0.0.24 and newer are much simplified. Here's 1.0.0.25:

 Depends: libc6, libgl1-mesa-dri, libgl1-mesa-glx, xterm | gnome-terminal, zenity
jon
@Colin: ah, yes. The multiarch-support bit is a relic of when I was looking into installing alongside wheezy's libc version and can be ignored. I'll remove it in a later edit.
jon
new steam-launcher packages need jokey-common and repack doesn't work correctly anymore
Comment by kurojishi