Steam for Linux > Feature Requests/Recommendations > Подробности за темата
Tele42 6 декември 2012 в 12:25след.
Feature Request: Generic Dependency Catcher
If the situation with missing dependencies remain how it is now, most if not all game developers will end up packaging libraries that most users already have in order to cover fringe cases.

It would be beneficial if there was a generic catch-all for missing dependencies in the steam client and the games launched from it. When a game dies due to missing dependencies steam could give the user a message like xx game died due to missing libyy.so. That would give users something to throw in the browser and find the distro-specific help they need. As long as it is a unique message, then the users will take care of themselves. This is intended to be a fail-over mechanism for all distros your team does not intend to directly support. As far as I can tell LD_DEBUG=libs contains all libraries that failed to load.

I would also like to request a small public api to go with the dependency catcher, so that the developers for their individual distros can resolve missing dependencies to their package managers without additional effort by Valve staff. An alternative is to pass the missing dependency to a glue script that is called with the dialog and allow the distro devs to adapt the script to their package manager.

Your team has been pro-actively addressing dependencies and this a retroactive approach for all the unforeseen cases. Also, this allows for steam to be properly integrated into unsupported distros and means that every game developer does not need to make their own dependency checker and the look and feel is unified across the steam platform.

The end goal of this feature request is to reduce the amount of repeated effort by Valve staff and allow the community to support steam in this matter.

Note for Valve: this idea has already been submitted via email, I am posting it to the forum for community review and feedback.

Since I sent that email, I have thought of some more details to add.

First, the API or script should be able to return pass/fail/relaunch to the steam client upon completion, with relaunch containing no additional information, so that there is chance of a future input vulnerability.

Second, this same interface could be used proactively, by having the applications report their dependency needs to steam, the steam client could test for the presence of the library, then pass a list of libraries to the adaptor script.

Third, there may be a need for an optional field per dependency when there is 32-bit only library required (example: libpci.so.3,32) so that the script can translate it to the appropreate package.

As mentioned before, this is a fail-over solution for the steam client to work ideally on distros that steam does not intend to directly manage. The adaptor program or script should be part of their package manager and should not have need any logic to select the correct package manager. In other words, it needs to be part of the steam installer package, not part of the mainstream steam update method.
Показване на 1-15 от 37 коментара
< >
kigucdoshu 6 декември 2012 в 1:06след. 
Fantastic idea. I would love to see this implemented.
A(II) Rh+ 6 декември 2012 в 1:18след. 
What if a distro does not have a package manager or an adaptor? What if a distro does not provide the package at all? What if a game needs a specific version of the library?

A little story.
Recentrly I decided to play Penumbra. I took data files from Windows and found Linux binaries. I installed all the needed packages from Arch Linux repo. I even had to build some packages myself. The game started but was crashing at some point. The newest version of libvorbis was the reason. Once I found an older version of the library in one of Ubuntu packages, it stopped crashing.

The best way to ship games is bundling every needed binary, except libx, libgl etc. This way is proven on Windows and MacOS.
Flaming Sapz 6 декември 2012 в 1:19след. 
+1 Well put.
Orteko 6 декември 2012 в 1:22след. 
Something like this is definitely needed - we don't want to re-invent the wheel for package management.

Unlike windows it's already a solved problem in linux - it just happens to be solved in a couple of different ways :)
Tele42 6 декември 2012 в 1:22след. 
Първоначално публикувано от A(II) Rh+:
What if a distro does not have a package manager or an adaptor? What if a distro does not provide the package at all? What if a game needs a specific version of the library?
As I wrote, the steam client still reports the missing library while giving the adaptor script a chance to resolve the issue, this is for two reasons, 1) keep the user informed, and 2) give the user vital information if the script dies silently.
Rain Ninja 6 декември 2012 в 1:39след. 
+1.

Though I'd just be much happier if it brought up the message saying which libraries are missing, I think like Desura does (?), instead of just dying silently which is no help at all.
whiskydotjar 6 декември 2012 в 1:52след. 
It would be awesome!
A(II) Rh+ 6 декември 2012 в 1:53след. 
Look at doom3 for Linux, they even put libstdc++.so.6 in the installer. It was released 8 years ago, and it runs today without asking any 'dependencies'. I'm pretty sure, 8 more years will pass and doom3 will still work on any distro.

The less the user needs to do anything in order to play a paid game, the better it is for everyone, including Valve.

The idea to watch game output for missing library messages is not a bad idea. But for debug purposes only, to ask the publisher to update game installation.
slight 6 декември 2012 в 1:58след. 
I think it would be better for Steam to handle the deps itself. When Linux game is added to Steam it would list which libs and versions it needs. If they're not already required for some other game then they get added to Steam. Steam would fetch any required libs in their required versions when you install a game. It's not realistic to expect to manage games' libs via distro package management. Eventually the distro will drop the version the game requires. These aren't oss projects so it's not just a case of a maintainer rebuilding them when a new version of the distro is released.
johndrinkwater [🐧︀ 🎮] 6 декември 2012 в 2:01след. 
+1, +2 if you could enable packagekit to solve the cross-distro package prob.
Rain Ninja 6 декември 2012 в 3:43след. 
Or if let's say Valve wanted to do a compromise of both systems; i.e games would be bundled with libs as they do, but some sort of API detects whether you already have the exact lib the game requires and instead of downloading another copy of that lib in it's game folder, it simply links to the system copy. Is that possible/feasible?
Tele42 6 декември 2012 в 3:49след. 
The failed return value from the adaptor script could tell steam that it needs to grab a static version of a dependency and put it in ~/.local/share/Steam/ubuntu12_32/ or where ever Valve wants to put a pool of common libraries as a LD location
A(II) Rh+ 7 декември 2012 в 3:06сут. 
So why not download all needed stuff together with the game? Today's games are gigabytes in size, so a few extra files won't hurt the disk space.
mjau 7 декември 2012 в 3:56сут. 
Първоначално публикувано от A(II) Rh+:
The best way to ship games is bundling every needed binary, except libx, libgl etc. This way is proven on Windows and MacOS.

Agreed. There's just so many things that can go wrong with either system-provided or one common set of libraries for all games (configuration differences, complex version interdependencies and incompabilities, etc), that saving a few megabytes of disk space just isn't worth it. It's actually better both for users and developers if games just come with everything they need to run (except for system libs like glibc, X, OpenGL, ALSA, etc). It's better for users because the games simply work, and it's better for developers because the games are run with a known set of libraries, which can make debugging considerably easier.
Beamboom[Linux] 7 декември 2012 в 4:27сут. 
In reply to those who think all games should come bundled with all required libraries:
I don't experience problems with system-provided libraries with any other application I use on Linux (and, as Linux is my system software both at work and private that means a *lot* of various usage and applications) so why should this pose such a big problem for game applications?
Показване на 1-15 от 37 коментара
< >
На страница: 15 30 50