Augh. Some really craptastic distro-specific code in there. The wrapper script tries to detect missing dependencies on its own (gee... aren't package dependencies already handled by something, maybe the package manager?) and install them via "gksudo apt-get ...". Sigh...
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.
Those things are explicitly added post-install because a package can't have cross-architecture dependencies and not all the 10.4 packages support multiarch. For example, if your 32-bit package depends on xboxdrv, it can't install on an Ubuntu 10.4 x64 system. (ditto for libappindicator1, jockey-common, etc) I don't see how defining our own repository helps this problem at all. (and isn't what dropbox, chrome, etc. do anyway)
Hah! I knew you guys were watching. First, I'm quite certain that is what dropbox and chrome do, but I'll leave research to you if you like.
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.
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.
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!
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.
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.
I'm still not following. There's no (sane) reason I can see you can't ship your own 64 bit binaries. Obviously some of your games aren't going to qualify, but you'll need your own library manager for that stuff anyway. Why must the client install be such a mess?
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.
If providing a 64 bit binary is a "port" for this product then I suspect you have more tough love forthcoming. Really, the rest of the universe can just "build" across architectures (and I recognize that you probably can't control your partner's code and need to do multilib for the games, but really -- you couldn't make it work on your own code?). But this thread is long enough already. Just realize that you're not inspiring confidence here... Also look at Skype on Fedora for an example of a 32-bit-only multilib aware commercial product.
I'm not in the beta (just used the download link above) so sadly I lack such a channel. But broadly in my experience your suggestion simply doesn't work. Betas are for bug reports. Criticism of the code never makes it to the dev team, period.
On the other hand, it strikes me as quite likely that some of them read HN...
This might sound ridiculous, but Valve are actually really good at responding, or at least reading, emails sent right to the top. If you just send your thoughts to gaben@valvesoftware.com, I'm sure he'll forward it to whoever it's relevant to.
(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 :])
I've always been curious - is it known whether Gabe himself actually reads emails from non-employees sent to that address, or could it just be an assistant that handles routing most of the emails? I really can't imagine how he could possibly have time to deal with a public email account, but maybe I'm overestimating the volume of email he would get...
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.