Valve: come on guys, get it right. Look at how Chrome or Dropbox do this for a clean example. Basically, you define your own repository and your "install now" link simply adds it (and its key) and pulls your package via apt/yum/zypper/whatever.
Thanks for the feedback though.
And yes: getting cross distro (and especially multilib) support working is a big mess. But what you're doing is just awful. The scripts as-is are completely unusable on a Fedora box, because you've mixed "maintain the package installation" with "check for updates" with "run the binary" in a way that can't be cleanly separated. I'd literally have to rewrite most of your stuff just to use it, and that's dumb. Other providers (Skype is another good example, by the way) don't have this problem. Please study their solutions.
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.
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!
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.
First, I want to correct my typo - we are initially targeting Ubuntu 12.04 LTS (not 10.4 as I fat-fingered above) We are not looking at other distros in this limited beta release but obviously we don't want to do anything to preclude this in the future.
The dropbox and chrome examples are a little different. They ship both 32-bit and 64-bit .debs so they don't hit the multi-arch issues we did. Try to install the 32-bit dropbox .deb on x64 Ubuntu 12.04 and you will see the same problem (python-gtk2:i386 conflicts with python-gtk2)
Hopefully we can get the multiarch issues ironed out with Canonical (a lot of problems have already been fixed in updates). Believe me, I would like nothing better than to remove the gross hacks.
And again, I'm not part of the beta so I really can't comment on your forums. If I'm going to deliver tough love it has to be here, sorry.
On the other hand, it strikes me as quite likely that some of them read HN...
(I say this from experience - I sent him an email saying I thought the end of Half Life 2: Episode 2 was really fantastic stuff, and got a response back from the script writer, who he had forwarded the email to :])
please follow the xdg-user-dirs spec instead of sticking ~/.steam ~/.steampath ~/.steampid and ~/Steam in my home directory.
This is the kind of thing that should be caught very early if you don't want to be stuck with migration scripts and corner cases.
If $HOME/steam exists before installation, some files goes into $HOME/steam other in $HOME/Steam. And the installation fails.
Can beta participants invite others?
Edit: To clarify, I have lots of indie games on steam that are readily installable on Linux. TF2 doesn't seem to be available without beta access though.