[pja]

Seconding this: Doing a post-post-install in a script installed in /usr/bin is horrible!

Is targeting Ubuntu 10.4 a hard requirement? I suppose it's the last LTS release, but surely the users Valve is targetting would almost all have upgraded past 10.4 by now, and the 12.04 LTS release has already happened. Anything more recent than 11.04 has proper mutli-arch support in dpkg/apt so you can specify that your package needs both 64 and 32 bit versions of some packages.

Your approach seems extremely fragile: is seamless 10.04 support such a necessity?

Incidentally, your compiled binary is compiled against a more recent libc than was shipped in Ubuntu 10.4, so it will currently refuse to run on 10.4 anyway. I'm guessing you compiled in on an Ubuntu 12.04 install, since it has a hard requirement for a libc version 2.15 or above. This means it won't run on anything older than Ubuntu (12.04), nor will it run on the current or the next Debian release.

[pja]

Ha! After some gruesome hackery, I got it running on the Debian testing release.

A few small bug reports:

1) Your code to check who is in the closed beta is clearly not working :)

2) In the install dialog, asking whether or not to "Create a start menu shortcut to <game X>" is clearly meaningless :)

3) For some reason, Psychonauts is in my library (I own a copy on Windows), but I can't install it. Once past the dialogs, the install complete instantly & the gui believes it to be installed, but (unsurprisingly, since nothing has been downloaded) it won't run. Installing WorldOfGoo works perfectly.

4) You're re-setting LD_LIBRARY_PATH somewhere, which means that I can't actually play any of the games, even though I can install them, because they're finding the wrong libraries.

5) Running the games directly from the command line doesn't work, because they can't find a running steam instance to authenticate against, even though steam is running fine (this might be expected behaviour at this point, even though it works under windows obv.) I suspect this is related to (4): forcibly preloading everything in .steam/bin fixes the linking problem at least.

The Steam GUI seems perfect though: responsive & the look and feel is much the same as the Windows version. Bravo!

[pja]

NB. Big Picture mode is lovely: I'd never played with it under windows.

[pja]

And it works really well with the open source radeon drivers too!

[ajross]

Yeah, it really looks like this was built with essentially no view to binary compatibility (i.e. they did it on Precise simply because that's what they had on their desktops) and then tried to bolt-on multilib and cross-version (cross-distro was clearly chucked as far out the window as they could throw it) features right before beta. Then they added a bunch of "checking" stuff to the scripts "just to be sure".

Broadly, the best way to do this looks like this:

0. Build on 10.04 Lucid. Of the existing "well-supported" distro choices, it is binary compatible with more of the rest of the universe (including modern Fedora/OpenSUSE too!).

1. Identify dependencies on distro-provided software very early, and document them precisely. Things like the "xboxdrv" hacks mentioned above shouldn't exist; if you can't get it everywhere you need your own copy. It sucks but it's true. Building this stuff from scratch really isn't rocket surgery. A Lucid-built library will (absent missing dependencies) work on more modern distros, I promise.

1a. Conversely, if you can get something from the distro reliably, please do!

2. Separate the "update" mechanism from the binaries! Running steam should simply run steam. Put a "there is a new version" check in there if you must, but don't invoke the package manager on behalf of the user! If there are dependencies missing, you shouldn't be running at all.

3. Maintain your own apt (and ideally yum/zypper) repos. This allows you to cryptographically sign your distributed software in a way that the users and their tools already understand. And frankly it's something you need, and aren't likely do (or do correctly) for yourself anyway.

Doing things like this ensures that those of us who aren't on your preferred distro can still run your software without hating you. This is Linux -- you don't need to bend over backwards to support us. We're happy to do some porting work, just don't crap on us like you're doing now.