4 ms·

The Steam executable, libraries, data files, and games install with user permissions. This way games can install and update, and Steam itself can auto-update, w

The Steam executable, libraries, data files, and games install with user permissions. This way games can install and update, and Steam itself can auto-update, without privledge escalation. Windows and Mac versions behave this way. There is a launcher script that is installed in /usr/bin/steam. There was strong feedback from users that updating this script should belong to the system package manager. This is why the repo exists - so this script can be updated and managed by the system package manager.

drivebyacct2 14y ago
This isn't directed at you, but that sounds like exactly what I'd expect of someone who doesn't understand the point of package managers.
- Dylan16807 14y ago
  Package managers need better support for installing under a user.
  - drivebyacct2 14y ago
    1. I don't see a reason for Steam to be installed per-user. (First, the client ought to be a standard binary/assets that can be shared between users. Second, the games should too, though I know games currently are per-Steam-user in Windows anyway so I understand that game installs would be installed per-User, but that can easily be done by a globally installed Steam executable). 2. I'm pretty sure path prefixes can be used and the same set of pkg management tools can be used to install in user land. I've done it in the past into an env I was chrooting and minifying to power a picture frame.
    - throwaway64 14y ago
      path prefixes only generally apply to ./configure scripts when you are generating makefiles. As paths to libs and stuff are hardcoded as part of the ELF spec, it becomes difficult to implement something like this and ive not seen a package manager that can do it.
      - drivebyacct2 14y ago
        After looking more it appears that I was doing something that only works when targetting a chroot environment. My mistake. It would be interesting to think more about user-level applications and how that sort of trust would work, if it could.
        throwaway64 14y ago
        theoreticly you could work around the library/datafile issues with LD_PRELOAD hacks to make it load stuff from your home directory instead, but thats pretty awful.

drivebyacct2 14y ago

This isn't directed at you, but that sounds like exactly what I'd expect of someone who doesn't understand the point of package managers.

Dylan16807 14y ago
Package managers need better support for installing under a user.
- drivebyacct2 14y ago
  1. I don't see a reason for Steam to be installed per-user. (First, the client ought to be a standard binary/assets that can be shared between users. Second, the games should too, though I know games currently are per-Steam-user in Windows anyway so I understand that game installs would be installed per-User, but that can easily be done by a globally installed Steam executable). 2. I'm pretty sure path prefixes can be used and the same set of pkg management tools can be used to install in user land. I've done it in the past into an env I was chrooting and minifying to power a picture frame.
  - throwaway64 14y ago
    path prefixes only generally apply to ./configure scripts when you are generating makefiles. As paths to libs and stuff are hardcoded as part of the ELF spec, it becomes difficult to implement something like this and ive not seen a package manager that can do it.
    - drivebyacct2 14y ago
      After looking more it appears that I was doing something that only works when targetting a chroot environment. My mistake. It would be interesting to think more about user-level applications and how that sort of trust would work, if it could.
      - throwaway64 14y ago
        theoreticly you could work around the library/datafile issues with LD_PRELOAD hacks to make it load stuff from your home directory instead, but thats pretty awful.