Feature Request: Make sudo optional

[Psy-Q]

Not everyone likes to have sudo, it's more of a Ubuntu/Mac OS X thing and feels out of place on Debian GNU/Linux for example.

It seems that Steam is hardcoded to try to use sudo to install dependencies while installing games, but it could also detect kdesu, gksu or other graphical privilege elevation tools. It also seems to run the sudo command in an xterm window -- if sudo is not installed, it could detect this and spawn a shell in which the admin can su to root and install the packages by hand.

Not being paranoid, but it doesn't feel right to install something that affects the system's privilege system when it's actually not required for the system to work.

[v3nd3tta1337]

+1

[oneinfiniteloop]

This would be great if some script will handle all neccesary previleges escalations.
Something like system management api idea described here: http://steamcommunity.com/app/221410/discussions/7/846939071070067518/

[Febertrauma]

Another solution could be to use a sandbox mode to install dependencies in a local directory. Steam already bypasses the normal packaging system when installing software so why not break the normal conventions a bit more :-)

[BlackestDawn]

@Febertrauma
Why? It doesn't use such a sandbox on Windows (and I guess OS X).

It's perfectly fine for them to bypass the normal package handling when it comes to the games them self due to how and where they are installed. If they would go through the normal package handling then they would need to maintain their own repository with all the games for each officially supported distribution. Or if they are using some form of unified package they would to make sure every supported distro can actually use handle it, which would most likely make it go outside of the normal package handling system anyway.

[Febertrauma]

I'm not too familiar with OS X or Windows but my impression of windows is that they just store pretty much all library versions DLLs. Most linux distributions keep things organized and only keeps the dependencies needed for current binaries, and can build new binaries with updated dependencies as needed. A closed source app doesn't fit in that distribution model and going the windows way will conflict with how the distributions work today. Providing a sandbox environment could be a way to deliver a coherent package for multiple distributions with varying versions of libraries.

This also applies to the games, as stated they're already outside the package system, if the distribution is updated with ABI breaking libraries either the binaries must be replaced or provided with compatible libraries/wrappers.
I'd guess that the former isn't always possible.

Still, this is probably not the best way to go forward.

[BlackestDawn]

If the game really needs a specific version then the dev should bundle it with the game, no need for Valve to have a huuuuge repository of every library and every version of it, and having them built for every officially supported distro/version combination.

Fot the "sandboxing" to actually work as intended it would need to "sandbox" them on a per game basis, which effectively is the same as the game dev bundling them from the start. So in reality we should push for the devs to bundle the libraries that can cause such incompatibilities.

[Febertrauma]

No, the point was that if they sandbox they can keep a set of fixed libraries that devs build against and ignore the distro differences.

[BlackestDawn]

Right, so then Valve would effectively need to keep a full set of libraries AND keeping them updated, making sure that "old" games still run by either making sure the new versions of said libraries are backwards compatible, pushing the devs to recompile against the new versions or having several version of the same library installed. That is way too much work for the very very little benefit over just bundling the libraries with the game.

However, if the devs did build against these "Steam libraries" and wanted to put out a non-Steam version then they would need to either build against non-Steam versions of those libraries or bundle the Steam libraries. So in the end it's just soooooo much easier if the devs just bundle the "normal" versions they already have, since there is absolutely no advantage for Valve to make their own version of existing libraries when it wouldn't actually solve the big problem of library incompatabilities in the grand scheme (a.k.a both Steam and non-Steam environments).

[Febertrauma]

This is getting a bit off-topic, but I think it's an interesting discussion :-)

Agreed, it would effectively be a Valve distribution with multiple parallel lib versions. If the long term goal is a steambox, then perhaps that is what they're aiming at anyway.

Redundancy would still be an issue.
Building for multiple library targets is unavoidable if you want binary support for multiple distributions anyway (if you're doing it the nice way), and building for a known proven environment has its advantages.
OTOH, you can bundle the latest and greatest lib so it will give 3rd party devs more freedom.

There's advantages and disadvantages to both centralized and decentralized models, and I'm not sure doing a full binary distribution is the correct answer either way. Just leaving it as it is with just one officially supported LTS target distribution is certainly an option for now.
It would be nice to hear what plans Valve has up its sleeves...

[BlackestDawn]

I'm sure they won't go out of their way to give lib support under Linux the same why they don't go out of their way with DLL support under Windows, they only support the big "collections" (DirectX, Visual C redist and so on) and so through an already existing installation method.

If game devs needs to bundle their own speific version of (or obscure) DLL's under Windows then why not have the same policy/principle for Linux.


As for the original request, the only reason it is (seems?) hardcoded for apt right now is that it's only built to run on Ubuntu as of now. I certainly hope they have taken that into consideration and built that part of it in a modular fashion, that hopefully can be adjusted by third parties to make it functional for non-supported distros.

[☭ [ YUNG STALIN ] ☭]

I for one hope valve ignores these requests just to P.O. anyone who seriously considers this an issue.

[Artemis3]

Its not really out of place, simply not common. When you install Debian, at some point it will ask you if you want a root account, answer NO and will get the exact same ubuntu experience (the user account becomes a sudoer).

[Psy-Q]

Originalmente postado por IS THAT RACIST?:

I for one hope valve ignores these requests just to P.O. anyone who seriously considers this an issue.

Which part, the library part or the sudo part? The library part is a very valid discussion since there are some stupid decisions with unhappy consequences that Valve could take there.

If it's about sudo, can you explain why you think that it's not an issue?

Only two GNU/Linux distributions I know of install sudo by default, that's because that fits their respective philosophies. But other distros have other views and make a stronger distinction between plain user accounts and privileged ones. Why should I have to install something that is not necessary for my system to function but goes so deep that it hooks into the security mechanisms?

I guess it depends where you grew up. If you've spent time on Debian, you haven't needed sudo for over a decade. Why should a gaming service (of all things) force you to use it when there are suitable alternatives?

[K]

Why should steam be able to elevate access above userlevel to begin with? As for the package being outside the repo, that will most likely change once it's stable.

[Paul N. Maxwell]

I think Steam sould have some like /etc/steam.conf to define which mechnism sudo or su need to be used. By default 'sudo' sould to be set. More experienced users can change settings in this file manually.
I use Steam on Archlinux and sudo was disabled earlier. But with disabled sudo I cannot update my Steam client to latest version, because it cannon overwrite '/usr/bin/steam', because cannot get root previleges via sudo. But when I enabled sudo all is ok, but why every user like me must to do it?
This config can be used to select right tools to manage packages on OS. I think more experiences users can install needed libraries manually, so in this can Steam can just say user which libraries need to be installed. No need to force users to use Ubuntu because it's lots of work to make Steam capable to manage on every Linux distribution. This capability most needed no Ubuntu and similiar distributions, because Ubuntu used mostly by beginners.
This is my IMHO, sorry for my bad English.