Steam for Linux > 一般討論 > 主題細節
johnv 2012 年 12 月 17 日 @ 下午 1 時 22 分
Feedback on upcoming package install changes
We've gotten a lot of feedback around the hacky way that Steam manages dependencies. Some of this is because of lingering multiarch problems on Ubuntu 12.04 and hopefully this will go away as Canonical irons those out. But some is due to the way that package management doesn't work well with an auto-updating application like Steam. For example, if we add a new feature to Steam that requires a new OS package to be installed, we need to make sure that happens before the new auto-updated Steam runs. And with different distros having different approaches and interfaces to package management, it is impossible for us to cover all the different configurations.

One proposal we have to make things easier for other distros is to separate out the package management logic (basically the install_extra_packages() part of /usr/bin/steam.sh) into a separate script - steam-depends.sh. Then we would call that script to do any post-install package installs. Other distros could provide a different script that would do the equivalent.

I would love to get some feedback from people running (or trying to run) Steam on non-Ubuntu distros. Does this help some? Any better ideas?
顯示 1-15,共 113 則回應
< >
bryandamage 2012 年 12 月 17 日 @ 下午 1 時 44 分 
the separate script is probably necessary.
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?
dcatz 2012 年 12 月 18 日 @ 下午 12 時 44 分 
The dependencies themselves don't really take up much disk space, so it might be better to simply bundle the dependencies with each game and keep copies in each of the games folder. This way, version conflicts between libraries are avoided and you don't need to worry about distro-specific package management.
[Linux] SkiskiLive 2012 年 12 月 18 日 @ 下午 1 時 39 分 
One of the beauty of using a package manager is precisely to avoid to have librairies packaged with each software installed.

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 ?
dilworks 2012 年 12 月 18 日 @ 下午 2 時 35 分 
This boils down to a "static compile everything" (and bloat everything to hell) vs. "minimum common denominator" (figure out which ones are the most common distros and try to target to the lowest possible library versions).

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.
[LINUX]FinCoder 2012 年 12 月 18 日 @ 下午 2 時 41 分 
Why steam cannot update it's depency needs to the update manager? supportin few majors...
Cybertao 2012 年 12 月 18 日 @ 下午 2 時 45 分 
johnv 發表:
But some is due to the way that package management doesn't work well with an auto-updating application like Steam.
Well, that's your problem right there. Does Steam have to be auto-updating?
johnv 2012 年 12 月 18 日 @ 下午 4 時 44 分 
Cybertao 發表:
johnv 發表:
But some is due to the way that package management doesn't work well with an auto-updating application like Steam.
Well, that's your problem right there. Does Steam have to be auto-updating?

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.
dcatz 2012 年 12 月 18 日 @ 下午 8 時 14 分 
SkiskiLive 發表:
One of the beauty of using a package manager is precisely to avoid to have librairies packaged with each software installed.

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 ?

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).
Cybertao 2012 年 12 月 18 日 @ 下午 9 時 01 分 
You can get away with quite a bit when it comes to binary compatibility. As long as the APIs are constant between the binary and system libraries.
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.
最後修改者:Cybertao; 2012 年 12 月 18 日 @ 下午 9 時 26 分
[Linux] SkiskiLive 2012 年 12 月 18 日 @ 下午 10 時 53 分 
Moreover, if Valve doesn't make it easy for other developpers to port their games to linux, they won't do it. And if a developper has to check if its game works for any distro, with the correct dependencies, they won't do it.
Cybertao 2012 年 12 月 21 日 @ 上午 12 時 56 分 
Hmmm.

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 dicking us around.
最後修改者:Cybertao; 2012 年 12 月 21 日 @ 上午 1 時 00 分
LordBeDe 2012 年 12 月 23 日 @ 上午 3 時 59 分 
johnv 發表:
But some is due to the way that package management doesn't work well with an auto-updating application like Steam. For example, if we add a new feature to Steam that requires a new OS package to be installed, we need to make sure that happens before the new auto-updated Steam runs.

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.

[Linux] SkiskiLive 2012 年 12 月 23 日 @ 上午 6 時 08 分 
I think the problem is that your package manager cannot force you to update your packages. But with Steam, Valve wants to force the update whenever there is a new one. I'm not sure how the script will deal with it, but, in a nutshell, that's the problem.
Halber 2012 年 12 月 23 日 @ 上午 6 時 20 分 
Another cent for the discussion... how will you handle different games requiring different versions of a certain library? eg. installing game X will break game Y and vice versa?

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.
johnv 2012 年 12 月 27 日 @ 下午 1 時 50 分 
LordBeDe, it should be possible to install games and update them without having to be root. Obviously if a new system dependency is required, you will have to be root to install that, but the common case of simply updating a game or installing a new one shouldn't require root.
顯示 1-15,共 113 則回應
< >
每頁: 15 30 50
張貼日期: 2012 年 12 月 17 日 @ 下午 1 時 22 分
回覆: 113