It is weird, considering closed drivers have a huge shared codebase between sytems, that "beta drivers" are still needed in order to play games. I'm toying with Serious Sam 3, and even with "old" drivers (296 series under windows, 304 under Ubuntu 12.04, both stable), game is still playing good, considering I'm using the publicbeta channel, and seeing there are several fixes on the game side, not drivers. Can I assume that it's the same for other games ?
Considering the package format flamewar, deb, rpm, tgz, whatever it is, and how bad it can be configured, Valve is trying to do the same thing as on windows : be independant of the "admin rights" security, like on windows, and like Chrome (installing in Appdata instead of standard place just to be sure of permanent write permission : it's like installing in /home/user directory, not standard way). It may be the worse thing apart from being a closed software. Package dependancy handling has already been a problem for years between distros, I'm not expecting it to be solved magically just because Steam is coming.
Some Steam shortcomings that I hope they work out:
Let me jump into the discussion...
I understand the reason why they decided to go with Ubuntu (and hence .deb), as it is the percieved most widely used distribution, and also it is the upstream to a bunch of derivative distributions, even though it might stem from Debian itself. I agree with what others have stated about LSB, and as such I do reckon that "as part of LSB it would make more sense to go RPM", however a few .rpm based distributions have had traditionally differences in how they name their packages, etc... The way I see the package manager and dependency resolution problem would be to instead of relying on the distribution's package manager (apt, yum, etc) to abstract the dependencies to individual files (i.e libstdc++-6.0.so <i686>) and parse them to package-kit which would then use the local package manager to locate the appropriate package to satify said dependency.
Moving towards a more distro/package manager neutral dependency management (the way I understand it, any way) would necessarily go through PackageKit.
As to the "best" way to install Steam, I don't see any problem with it being a self-contained archive installable somewhere in the user's home directory or through package manager, in the end the behavior is the same as say GIMP, Mozilla, wine and other products: Have the core libraries installed system-wide, and locally needed files locally (by means of the currently used ~/.local/share/Steam/ path for Steam), and in such a way even that it could behave like some games in such that in-app updates override the system-wide application version, if say the system package managed version is not in sync with the in-app version. Some games allow this in their /main/directory Vs ~/home/.game directories, making the necessary adjustments in the launcher scripts by use of checks to assess the system Vs user's home directory versions of the components (with 'if' or 'case' statements).
Having spent some time (professionally) on MeeGo and the rpm system used in it, it seemed to me like the RPM was more susceptible to horrible database corruption than deb is. It could just be that I wasn't experienced in the use of the RPM, but the error messages it produced were definitely not very helpful.
RPM is however simpler to create packages for, aside from some silly staging requirements.