Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
how often would steam need new dependencies?
what is the time limit for updating steam? do i need to update now so i can play my games or can i wait?
i can see the scenario of steam updating, running the post install script and the dependencies not being met by the distribution's package manager.
this would prevent me playing my games.
a pre-install script would be better i think, but that would mean different people would be at difference revisions of the steam client, depending on how current their distro's packages are.
i am running on gentoo so a preinstall script would be preferable. i'd rather not start steam and then have to wait for an update to be downloaded and then wait for x dependency packages to be compiled before i can play.
is there a way to ensure the dependencies are able to be met before each steam install updates itself?
If is this script avoid to have to package dependencies with each game, it's better.
But, ain't the bulk of dependencies will come from all the games ? How will this dependencies will be handled ? Will they be packaged with the games ? Or will Steam ask to install them ?
Isn't the purpose of PackageKit to deal with this on any distro it is available ?
Multiarch surely will be a pain for a long time to come (and I've been a user of multiarch distros since Fedora Core 6, all the way up to Debian Wheezy... sadly, not much has changed in this front in 6 years), but in the meanwhile the separate script not only sounds like a good idea, it's the one and only way to go if you want to cause the least possible pain, both to packagers and to end-users.
Yes, it does. As do the games. Also, a .deb can't really install/update files that are user-specific and the bulk of the Steam files are in your HOME directory, not /usr/bin.
The problem is, each distro and version of a distro will have different versions of any given library. In addition, certain distros (mainly the bloated ones like Debian/Ubuntu/Fedora) have the bad habit of modifying upstream code and patching the libraries so that Library X Version Y on one distro is not the same as Library X Version Y on another distro even though it has the same name and version number. And that isn't even counting the fact that there are compile-time options and optional features that may or may not have been compiled in depending on the whims of the distro maintainer.
With free (libre) software, this isn't a problem. The distro maintainers ensure that all programs are compiled against the versions of the libraries that the use and provide and, really, all packages are coming from a single source (the distro). Steam operates outside the package manager (it installs the games itself) and deals with proprietary software; there is simply no way, short of releasing the source code of each and every game, to ensure that it is compiled against whatever version of the library happens to be on the system. The best option, therefore, for proprietary software, is to simply bundle the versions of the libraries they are compiled against (either put a copy of the relevant .so files in the program's directory or statically link).
Open-sourcing Steam and any of the games in it is clearly unreasonable, but definitely highlights part of the problem.
If the Steam client was distributed as package that included the list of dependencies from a repository then Steam client updates would happen transparently along with any other system updates. The package manager would also record that the packages are there because Steam needs them. The package that bootstraps the real installer is half-way there. Users will be dependent on the repository/package manager for prompt updates, but the current hack is likely to break and rely on maintainers anyway.
The client doesn't have to reside in /home. Having it somewhere such as /usr/games or /opt and separating the data+games in /home (the way it's supposed to be) would also allow the same client to be used by multiple users (even though that's probably a rare event) and protect the client from being modified by anything or anyone unless they have superuser permissions.
The games are another story though and a calamity waiting to happen. Since Ubuntu is the platform Valve are targeting for consistency it wouldn't be out of line for Valve to specify a development platform of packages expected on the system, leaving anything more as the developer's problem to solve by somehow including the functionality with their game or installing libraries to a common directory.
Some will scream blue-murder at the totalitarianism of it all, but the best way for maintainers of other distributions to respond quickly is standardisation and consistency.
I don't use the Mac much so I don't use Steam on it, but have it installed. My son (who does use the Mac) was curious about a game so I told him to take a look in Steam.
It hasn't been opened in a while so needed to update. The interesting thing was the window didn't have the black Steam decoration, it was a standard Mac decoration. And it asked for a system administrator password as my son's doesn't have admin permissions.
With Valve not wanting to update the Steam client (and dependencies needed for the client) through package management, I'm starting to wonder if they are ♥♥♥♥♥♥♥ us around.
I don't understand how that problem can not be solved with the standard package managers. One of their jobs is exactly making sure that dependencies are fullfilled.
It should be possible to have http://apt.steampowered.com be a Valve managed Debian repository that has a clean steam*.deb package.
From within Steam Client you could check the installed version against an online source, and if there is a newer one available in the repository notify the user.
You could even add buttons to the notification to either run apt-get update/apt-get install steam*deb, or ask the use to update it by themselfs or even start synaptic or another package manager.
The beauty of that is you can let the package manager do what it does best and you won't have to reinvent the wheel.
Also this can work for rpm based distibutions, you'd just need to provide f.e. a yum respoitory.
For game dependencies you could use meta packages, e.g. an empty package that has the same dependencies as the game, e.g. steam-dep-portal2.deb => libgtk1.2, libtcl5.2, ...
While you will need to create these meta packages for every game and distro, this is something you need to do anyway. You need to track which dependencie needs to be installed for each game on what distribution. So there is no extra work involved when using the package maneger but you gain the benefit of it doing the dependency job for you.
It all really boils down to 'bundle required libraries with the games'...
As for the steam client itself...I like LordBeDe's suggestion. Just refuse to start when the wrong version is installed and give the user (or his admin) a hint how to update.