steamdeps is nonsense and should be completely removed, replaced by regular package dependecies. Or at least not distributed in .deb packages.
Hi! I am one developer of PackageKit, a cross-distro solution to install distribution packages and query package details. I also develop Listaller, a cross-distro 3rd-party application installer, which faces similar issues like you do with Steam.
You could easily use the PackageKit APIs to provide functions used in Steamdeps, and because Listaller had similar issues in resolving dependencies, I am currently working on making this as easy as possible.
So, if you have questions about distro package management and PackageKit, please just ask me!
Also, there is this hint in the code: "Function to install or update package dependencies. Ideally we would call some sort of system UI that users were familiar with to do this, but nothing that exists yet does what we need."
Well, that is exactly what PackageKit is (well, not the UI, but an underlying system service which makes it possible for desktops to show the right UI dialogs). I would of course like to know which features you need in PackageKit. ;-) (So we have a chance to add missing stuff in future releases - but PK is already pretty complete, so I don't think there is anything missing)
:+1: for real cross-distro dependency resolution using http://www.packagekit.org/
at least the dependencies should be exactly .so libraries so every distro can resolve that deps in its way
The current solution for openSUSE is to simply rm /usr/bin/steamdeps during package installation.
For exactly this purpose we developed WhatProvides() for PackageKit. See http://gitorious.org/packagekit/packagekit/blobs/master/docs/provides-component-naming.txt for supported types.
I am currently working on a better implementation of WhatProvides() for Debian/Ubuntu (will need discussion with other Debian members first), because at the moment, support for this is not very efficient. (But Ubuntu uses this stuff already in some cases) All other distributions can support WhatProvides() for shared libs easily, and if they do it in a PackageKit backend, it will be available to all applications using the system service, not just Steam.
The basic workflow is:
This is basically how Listaller works too, to have distribution-neutral software installations :-)
PackageKit API docs can be found here: http://www.packagekit.org/gtk-doc/ Only the PkTask class should be required for this.
The PackageKit user interfaces are available for GNOME and KDE and will handle all the UI stuff nicely.
@Ximion hmm, maybe you can provide that packagekit version of steamdeps :)
(and what is kde interface? I've only seen gnome version in my portage)
@pashazz That could be done, but unfortunately I am working on too much stuff already and don't have the time to implement it right now. (I also like the C API more :P) But if nothing happens until April, I might rework steamdeps to use PackageKit. (I might have time for it in April :P)
If someone else wants to do this, go for it! (But I would like to hear a reply from Valve about this...)
The KDE frontend is called "Apper" and provides an integrated approach for software management. Your distro should provide it, if not you'll find the sources here: http://download.kde.org/stable/apper/0.8.0/src/apper-0.8.0.tar.bz2.mirrorlist
Thanks, I'll give it a try when I have time for it, found it :+1:
http://spot.fedorapeople.org/ has started some patches https://gist.github.com/Mailaender/4973797
this is so ugly until steam stops to use debian-specific deps...
Hmm, this patch is just a huge hack... The Steam binary would have to be changed to at least submit library names to create a sane fix.
@pashazz Yes, I read that after I submitted my comment (the entrys were reported at the same time).
What I would like to know is what "[...]Ideally we would call some sort of system UI that users were familiar with to do this, but nothing that exists yet does what we need." means. Because PackageKit is exactly that, and it works on all distributions. ;-)
Also, we can always make changes on system APIs if Valve would be missing a certain feature. (but I can't think of anything which would be missing)
let's cast @triage-valve - this is all we can at this point.
Can you install dependencies with PackageKit from the command line so that this python script can be adapted? That might be cleaner and more universal than my previous thought of using meta-packages or browser based triggers. Is there actually a use-case for this steamdeps script? I don't own many Steam games.
the most clear way is to remove that awful thing and use packagekit - "some sort of system UI"
This all leads back to my original recommendation at http://steamcommunity.com/app/221410/discussions/7/846939071070067518/ As for packagekit, if steamdeps gets fixed, then it can be used as a universal solution for some distros, but it is at the discretion of individual distro maintainers to decide if it is right for them. I expect many smaller distros would benefit from packagekit. I see no reason why packagekit would not co-exist with the same interface used to feed other package managers.
@Mailaender There is a cli available (pkcon), but the preferred way to access PackageKit from Python is via the GIR. Just install the typelibs and import PackageKit like:
from gi.repository import PackageKitGlib as PackageKit
done. You can then access the PackageKit API. (the function calls are similar to the ones used in the C API - but there are also some snippets around showing how to use PK from Python)
Just for the record, I am a Debian developer and also not happy with the current state - there already is some breakage between the Ubuntu version and Debian, also Steam does not integrate well with KDE and the shortcut function does not comply with XDG specs and places stuff on the desktop, which e.g. is not used in GNOME3. It works best with Ubuntu at time, so everything which makes Steam more distro-agnostic is great. ;-)
@Tele42 Yes. PackageKit already contains backends for many package managers and does all the abstraction. I don't see a need for every distributor abstracting the package manager interfaces again and just for Steam.
openSUSE is moving away from it's own SuSEconfig/YaST to PackageKit. https://news.opensuse.org/2013/02/07/heat-up-our-servers-12-3-rc1-is-ready-to-download/ promises many improvements and fixes with PackageKit interoperability.
@Ximion I am not against PackageKit in any way, I'm just asking for a solution that allows the community to be able to adapt to other solutions as well. What I'm asking for is that the script that interfaces to PackageKit remains in the open so it can be adjusted to other solutions should an individual distro decide PackageKit is not right for them.
How about just adding the multiarch dependencies in the Steam .deb and leaving it at that...
Maybe use pkgconfig strings?
@Tele42 I didn't read it like you were against anything ;-) Sorry if my reply sounded like this... I just think it might be better for Valve to implement PackageKit dependency resolving, while the distributors just need to tweak their PackageKit backends. By solving it that way, every distributor only needs to do the work once and it is available for all applications, not only Steam. And many distributors already have excellent PackageKit backends.
@Mailaender Using pkgconfig strings would be possible, but it might be easier to just submit the name of the library the application was linked against.
Nothing extracted yet.
Maybe you could fall back to https://github.com/anyc/steam-overlay/blob/master/games-util/steam-base/files/steamdeps on not yet officially supported distributions for now. It is a simple dialog which packages are missing so that the user can install them manually.
I also don't like xterm opening which looks quite hacky and alien on modern desktops. You should switch to web-based package installation triggers like https://en.opensuse.org/openSUSE:One_Click_Install or https://wiki.ubuntu.com/AptUrl.