I mostly agree with you. But I suggest to make a simple bootstrap installer that doesn't ask for root password and doesn't go further a home folder. Steam resides in home, freely creates things in it, and updates itself.

So why the deb package is really needed? It doesn't actually installs, nor it updates the entire steam, and it won't uninstall files from user's home. It is useless.

Hi, A(II) Rh+, the package is mostly to correctly install dependencies, but could also install the bootstrap, browser handler for steam:// urls, icons to use system wide, and maybe a simple script to run steam/bootstrap.

They have said that will support more than just Ubuntu, they just chose that one to start with.

As for the dependencies, outside of the Steam client itself that is up to the individual game devs and not something Valve is doing before publishing the games. Nor should Valve concern them self with such matters outside of giving the devs a way to "ask" for the larger "libraries" (like Mono, libSDL and such).One can hope that they make that part modular so we can plug in our own way of handling those requests, so we can check if it is already installed instead of just trying to re-install it.

Serious Sam 3 forced me to install a 32bit version of pciutils. Its stupid :)Second. Steam wants root permissions with sudo. Some people talk things like "trust valve" ... ♥♥♥♥♥♥♥♥. Steam does not need root permissions and should not get them. Its dangerous, its stupid, its windows style.

+1 to this. Providing a targeted package for Ubuntu is fine, I understand the need for it.

That said, the time to abstract the software from the environment is now, in Beta.

For example, things like hard coded dependencies on ubuntu-specific package names should not exist; there are distro-agnostic tools to help the application locate the required libraries.

Similarly, there should be absolutely no invocations of apt-get or similar in the application logic. I want my package manager to update the software - I don't want to put the software in charge of the package manager. Dependencies should be resolved when packaging, not at runtime. If it is absolutely necessary to interact with the package manager during runtime, the application should be talking to PackageKit, not a specific package manager. This isn't my personal preference, this is simply best practices coding.

Every distribution packages software from an upstream source. They are all taking a tarball or similar and wrapping it in a nice, friendly package. They are all using the same upstream sources. Each distribution provides ample process documentation and interactive support for packaging, and I suggest that Steam take advantage of the resources provided by the linux community *early* in the development process.

They have said that will support more than just Ubuntu, they just chose that one to start with.

As for the dependencies, outside of the Steam client itself that is up to the individual game devs and not something Valve is doing before publishing the games. Nor should Valve concern them self with such matters outside of giving the devs a way to "ask" for the larger "libraries" (like Mono, libSDL and such).One can hope that they make that part modular so we can plug in our own way of handling those requests, so we can check if it is already installed instead of just trying to re-install it.

excelent Idea blacke4dawn!

I think that is a good point they could start an opensource project to develop this cross distro dependency stuff ;)

There is a lot of truth in what you guys are saying, but there is also one logical error. You have to consider that detail otherwise I don't think you will get Valve's ear. (Note that I'm saying this based on my opinions and experiences, so it might not be what Valve thinks, but speaking from a gamedev perspective I hope it can shed some light on some factors that you are probably unaware of.)

I don't think that Steam can be put under complete and sole jurisdiction of each distro's package manager(s). The reason is that it must be updated exactly when Valve says. It must be done so in order to facilitate quick response for patches. This is something you wouldn't need for some general commercial software (office, Photoshop...), but Steam client is very network-dependent and must be reasonably up to date, especially as features in games depend on it.

So, we get a bit of a chicken-egg problem here. If individual distros will be repackaging Steam client, the client will still want to overwrite itself. It cannot wait for all maintainers to repackage each update. A usual solution would be for the provider (Valve) to maintain a repo for each distro or at least a package format. I doubt that will happen, as it would be too involving. (And it would duplicate a lot of functionality that the client already does, which would be a problem for them, I guess. As it is now, the installer for Windows and OSX seems to be always a bit older version, but then it autoupdates itself. Considering the fact that Steam is a software distribution platform, it is only reasonable to expect that it updates itself. :) If I were in their place, I'd keep it that way.)

So unless I'm totally wrong, I think crying "thou shalt use the package manager" will not be deemed constructive by Valve. I think that a more constructive discussion would be how to arrange Steam to be installed by the package manager, and yet have it autoupdate itself.

My humble idea is to perhaps have package manager install a "bootstrapper" (which can be the same what it is in the .deb file now), but to have it adjusted to install the actual used Steam instance into a different folder. Then autoupdater wouldn't have to overwrite pm-created files (which I agree is a bit of a bad approach), and distros could repackage the bootstraper as they like. Now, I'm not saying that this is "the solution". Just something to get the discussion going.

I bet that if the Linux community puts their heads together they can come up with some nice suggestions, and it will be more useful than just reciting the same rites even when it doesn't apply. JM2C. And I repeat - this is my opinion, not that of Valve, but I hope it is at least a bit on the right track.

As I said the package will only contain a simple bootstrap, browser integration and stuff. Not the hole steam. The bootstrap will go and download latest steam version install and run it.

Then it would be the hardest part: a middleware API to integrate steam/games dependencies into the local package manager, the distribution creator would just develop the middleware to communicate to steam and download this dependencies.

Still I think that most games should bring most of its dependencies locally, and load it with ld_preload stuff.

A package in each distro like they have now with the bootstrap script isn't bad. Just enough to make sure the required dependencies remain installed and up to date, then steam keeps itself up to date on it's own like it does now. A decent compromise that should allow steam to work for all users across all distributions. Valve's side would basically just be to provide the script and a README or something with basic information and a list of dependencies in a .tar.gz or whatever that package maintainers can keep up to date. It'd also be small so there shouldn't be much delay between dependency changes and package updates. I suppose steam's auto-updater can even fetch a list of libraries and library versions that are needed and notify the user that they should run a system update before going through with the steam update, and provide an expandable "Details" section listing libraries that they don't have or that are out of date.

There are good reasons for the Steam client to make sure it is updated before each use. I think that's a great idea, considering the obvious security concerns.

One way to handle this is as above: Steam can forgo the native tools and write their own code to handle the problem of updating software and resolving dependencies. This sounds like a lot of work to me, and I think that developer time could be better used solving problems that don't already have native solutions.

I agree with immanetize, the more I look at PackageKit the more it looks to be the most optimal solution. And if I understand it correctly you can configure it to only be able to update (possibly only itself), not install new or remove existing.

I don't think that updating already installed system packages is what is of concern here. There are two things that need to be handled: Steam autoupdating itself, and Steam (or games) installing new packages as needed for new games.

PackageKit looks interesting!I think that PackageKit should be used to:

1- Handle steam dependencies if you download "non-packaged" version of steam (a .tar.gz version or a mojo setup version)

2- Handle Steam games dependencies

And what shouldn't do:

1- Instal Steam (steam client software) dependencies in packaged version (such as DEB, RPM etc), which should be handled by packages dependencies itself.

And now another Idea for the whole thing:

This is more radical but will provide a more "stable" and easy to handle environment for steam: Install STEAM inside a chroot-like environment (maybe a ubuntu chroot). Steam itself will download and install all needed depencies. It will be like a linux distro for steam that will reside inside of your actual distro in a chroot-like space.

Pro about that is this way STEAM will be more apealing for game developers as it will be much easier to maintain, since all environments will be equal independent of distro or whathever package manager the person will be using

Cons about that: It will duplicate A LOT of packages in your operating system, and valve will need to maintain a larger and more complex codebase. Purists linux users will (for sure) feel offended by that.

Another con, game devs would be relegated to follow Valves update speed in regards to these libraries, which means that Valve would sometimes have to choose between keeping existing games running or getting new features into those libraries. No game as far as I know have ever been updated purely because there was newer libraries released that broke compatibility, there has always been something more done.It would also mean that the devs would need to wait for the library to even get into the "chroot environment" in the first place.

Really, even Windows games are bundling some DLLs where they need a specific version, iteration or whatever to make sure the one they use don't change unless they say so. Why should that mentality be so different just because it runs under Linux?

I would love it if games could exclusively use the libraries already present on the system but the fact is that we can't guaranty 100% backwards compatibility for the "lifetime" of that library, not even for major or even minor version numbering. And unless the devs release the source there will be a time when they stop updating it, and thus "freeze" the possibility to use libraries supplied and maintained by someone else.