6 ms·

I'm not 100% sure why they have a "repo" for an "installer". It sort of rather defeats the purpose. If they're going to do that, just put the client in a DEB an

I'm not 100% sure why they have a "repo" for an "installer". It sort of rather defeats the purpose. If they're going to do that, just put the client in a DEB and put that in the repo. At this point I see no reason in adding the repo to apt. Either way, it'll get sorted, Steam for Linux is already quite great. Still can't get over that TF2 runs better in a window in Linux than I've ever had it run in Windows.

w1ntermute 14y ago
> I'm not 100% sure why they have a "repo" for an "installer". It sort of rather defeats the purpose. It's because they don't really grasp yet how these things work on Linux. Which is understandable, since they're coming from a Windows world, where package management has to be done manually. So the Steam executable you download is an installer that downloads/installs the Steam package manager, which then downloads/maintains the games. Ideally, all the Steam Linux games would be maintained in APT repositories and you would update them through APT, but I don't know if that will ever happen. At least this is better than nothing at all.
- ceronman 14y ago
  That "ideal" solution would only work on deb based distros.
  - w1ntermute 14y ago
    Wrong, you could easily create similar repositories for other package management systems.
    - duaneb 14y ago
      At some point they need a downloadable installer, if only for e.g. gentoo or slackware.
      - w1ntermute 14y ago
        Not for Gentoo, which has overlays[0]. Slackware would be the exception, as it has no de facto package management solution. 0: http://www.gentoo.org/proj/en/overlays/userguide.xml http://www.gentoo.org/proj/en/overlays/userguide.xml
        duaneb 14y ago
        Well, the overlay needs to download something as well. So my point remains, I think.
        w1ntermute 14y ago
        No, it doesn't. I don't think that you understand how an overlay works. You run a command or modify a configuration file to add the overlay. Then you can install any packages in that overlay. Those packages would be the games. The package manager on Windows (Steam) isn't needed on Linux because there's already a native package manager on the majority of distros. In fact, you can already buy games through the Ubuntu package manager. I believe they're in a separate, "partners" repository. Steam should just be another repository like that.
- stephen_g 14y ago
  They'd have issues with their DRM doing that. They should ship the Steam binaries properly through apt and yum repositories, but I doubt that they'll ever ship the games that way.
  - thristian 14y ago
    I don't see why. If the Steam-DRM'd version of a game requires Steam installed in order to play, they can just add the Steam package as a dependency. Possibly a bigger issue would be that Steam has incremental updates (fixing a bug in a game requires downloading a fixed binary but not the multi-gigabyte data files) while most Linux package managers do not support incremental updates (when Debian releases a new LibreOffice package that fixes some dependencies for the s360 archictecture, I still have to download hundreds of megabytes of changes on amd64).
    - jiggy2011 14y ago
      There is also the issue that a Steam game may have dependencies on different versions of certain libraries than those which may be shipped with popular distros. You also have to think about people with custom PPAs etc. I think it makes sense for Steam to be isolated from the rest of the system as much as possible. It is also helpful to Valve if it is as consistent with Steam on other platforms as possible. Game downloads can be pretty big and take a while too, I'd rather not have apt locked for an hour while it grabs some large game update.
      - arnoooooo 14y ago
        The libraries can be installed from steam packages as well.
    - Maakuth 14y ago
      In Linux game packaging, this issue is often resolved by having a separate package for game data. This is also a neat workaround for licensing differences. For example Quake 3 is now open source, but the game data is still under commercial license. Distributions now offer just the game binaries built from the source and you have to buy the data yourself.
- fsniper 14y ago
  So if they "do not grasp yet how things work on Linux", Why they are not meeting Canonical guys and get some help? I believe they do things as they do now is they are looking forward for interoperability with other distros in their own way.
  - w1ntermute 14y ago
    > I believe they do things as they do now is they are looking forward for interoperability with other distros in their own way. Well, it's not working very well, since only Debian-based distros can directly install the software. And those distros could just add a repository anyway. Other distros, like Arch, are forced to create workarounds, such as scripts that download and extract the .deb[0]. 0: https://aur.archlinux.org/packages/steam/ https://aur.archlinux.org/packages/steam/
- Angostura 14y ago
  I remember when Steam was first launched for Mac; Valve decided to pop all the games' assets and support files into a folder in ~/Documents. It took a few days to explain to them that this probably wasn't the best place to dump a few GB of files. A lot of people's backups suddenly grew rather large.
- AdrianRossouw 14y ago
  it's best to think of steam as a new package manager for games, the same way you would have ruby gems or npm packages.
sandGorgon 14y ago
that is because they are keeping themselves open to have a Steam packaging format. It is something I have always bet that they will eventually do - once they see the number of support questions by people who have some sort of dependency problems (e.g [1], [2] and [3]). I wonder how long will it take for them to latch on to something like Zeroinstall or nix. [1] http://steamcommunity.com/app/221410/discussions/0/846940247664088606/ http://steamcommunity.com/app/221410/discussions/0/846940247... [2] http://steamcommunity.com/app/221410/discussions/1/846940247664767626/ http://steamcommunity.com/app/221410/discussions/1/846940247... [3] http://steamcommunity.com/app/221410/discussions/0/882965118613928324/ http://steamcommunity.com/app/221410/discussions/0/882965118...
- drivebyacct2 14y ago
  No, I understand not distributing the games in DEB form, but what's the point of versioning an installer that then goes and downloads the latest version of the client? Just put the client in the repo...
scottlu2 14y ago
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.
throwaway64 14y ago
Steam has a package so dependancies can be satisfied easily without resorting to "install xyz beforehand", and it runs an installer into your home folder because the user has to be able to modify the games directory for many, many games on steam, because stuff like configuration, custom maps, custom models etc, is stored alongside everything else. Also steam has diff based patching (which requires accress from whoever is running the steam binary) which makes a lot more sense than how package managers operate for large packages, imagine downloading an entire 20 gig game every time there was a minor bugfix, it would be very obnoxious. Unless the design of both package managers, and how steam games store settings/etc both change radically, this really is the only workable solution. Luckily, you will still be able to share steam folders cross user, just simply give both users read/write access to the folder.
- StavrosK 14y ago
  This is irrelevant. They can add the Steam binary to their own PPA and update it as they update the client now. Steam will be able to do all those thing, like every single program in Linux can, while being installed as a system package. The way they're doing it now is plain unclean.
  - throwaway64 14y ago
    how is it irrelivant? if people are wanting games and stuff to be distributed through the package manager, all these issues very much apply. Even the steam client package itself is something like 100megs, so it becomes painful without diff/delta patches. (steam updates a LOT)
    - StavrosK 14y ago
      I'm only talking about handling Steam updates, I agree with you on game updates. However, the Steam client can still access the user's home directory and create/access game data there, as all Linux apps do, so the current way of having Steam dump its binaries at the home dir is unclean. Pretty much the only valid point is having to update the whole thing every release, but I've never seen the Steam client download an update that was less than 75 MB.
pbhjpbhj 14y ago
So I thought I'd try and see what the score is: TF2 is 12.0 GB ... damn, that's hefty. This had better be the richest, smoothest, highest quality game; feature rich and expansive. That is about 11GB bigger than any [single] thing I've ever downloaded before. Estimated download completion time ... Christmas.

w1ntermute 14y ago

> I'm not 100% sure why they have a "repo" for an "installer". It sort of rather defeats the purpose. It's because they don't really grasp yet how these things work on Linux. Which is understandable, since they're coming from a Windows world, where package management has to be done manually. So the Steam executable you download is an installer that downloads/installs the Steam package manager, which then downloads/maintains the games. Ideally, all the Steam Linux games would be maintained in APT repositories and you would update them through APT, but I don't know if that will ever happen. At least this is better than nothing at all.

ceronman 14y ago
That "ideal" solution would only work on deb based distros.
- w1ntermute 14y ago
  Wrong, you could easily create similar repositories for other package management systems.
  - duaneb 14y ago
    At some point they need a downloadable installer, if only for e.g. gentoo or slackware.
    - w1ntermute 14y ago
      Not for Gentoo, which has overlays[0]. Slackware would be the exception, as it has no de facto package management solution. 0: http://www.gentoo.org/proj/en/overlays/userguide.xml http://www.gentoo.org/proj/en/overlays/userguide.xml
      - duaneb 14y ago
        Well, the overlay needs to download something as well. So my point remains, I think.
        w1ntermute 14y ago
        No, it doesn't. I don't think that you understand how an overlay works. You run a command or modify a configuration file to add the overlay. Then you can install any packages in that overlay. Those packages would be the games. The package manager on Windows (Steam) isn't needed on Linux because there's already a native package manager on the majority of distros. In fact, you can already buy games through the Ubuntu package manager. I believe they're in a separate, "partners" repository. Steam should just be another repository like that.
stephen_g 14y ago
They'd have issues with their DRM doing that. They should ship the Steam binaries properly through apt and yum repositories, but I doubt that they'll ever ship the games that way.
- thristian 14y ago
  I don't see why. If the Steam-DRM'd version of a game requires Steam installed in order to play, they can just add the Steam package as a dependency. Possibly a bigger issue would be that Steam has incremental updates (fixing a bug in a game requires downloading a fixed binary but not the multi-gigabyte data files) while most Linux package managers do not support incremental updates (when Debian releases a new LibreOffice package that fixes some dependencies for the s360 archictecture, I still have to download hundreds of megabytes of changes on amd64).
  - jiggy2011 14y ago
    There is also the issue that a Steam game may have dependencies on different versions of certain libraries than those which may be shipped with popular distros. You also have to think about people with custom PPAs etc. I think it makes sense for Steam to be isolated from the rest of the system as much as possible. It is also helpful to Valve if it is as consistent with Steam on other platforms as possible. Game downloads can be pretty big and take a while too, I'd rather not have apt locked for an hour while it grabs some large game update.
    - arnoooooo 14y ago
      The libraries can be installed from steam packages as well.
  - Maakuth 14y ago
    In Linux game packaging, this issue is often resolved by having a separate package for game data. This is also a neat workaround for licensing differences. For example Quake 3 is now open source, but the game data is still under commercial license. Distributions now offer just the game binaries built from the source and you have to buy the data yourself.
fsniper 14y ago
So if they "do not grasp yet how things work on Linux", Why they are not meeting Canonical guys and get some help? I believe they do things as they do now is they are looking forward for interoperability with other distros in their own way.
- w1ntermute 14y ago
  > I believe they do things as they do now is they are looking forward for interoperability with other distros in their own way. Well, it's not working very well, since only Debian-based distros can directly install the software. And those distros could just add a repository anyway. Other distros, like Arch, are forced to create workarounds, such as scripts that download and extract the .deb[0]. 0: https://aur.archlinux.org/packages/steam/ https://aur.archlinux.org/packages/steam/
Angostura 14y ago
I remember when Steam was first launched for Mac; Valve decided to pop all the games' assets and support files into a folder in ~/Documents. It took a few days to explain to them that this probably wasn't the best place to dump a few GB of files. A lot of people's backups suddenly grew rather large.
AdrianRossouw 14y ago
it's best to think of steam as a new package manager for games, the same way you would have ruby gems or npm packages.

sandGorgon 14y ago

that is because they are keeping themselves open to have a Steam packaging format. It is something I have always bet that they will eventually do - once they see the number of support questions by people who have some sort of dependency problems (e.g [1], [2] and [3]). I wonder how long will it take for them to latch on to something like Zeroinstall or nix. [1] http://steamcommunity.com/app/221410/discussions/0/846940247664088606/ http://steamcommunity.com/app/221410/discussions/0/846940247... [2] http://steamcommunity.com/app/221410/discussions/1/846940247664767626/ http://steamcommunity.com/app/221410/discussions/1/846940247... [3] http://steamcommunity.com/app/221410/discussions/0/882965118613928324/ http://steamcommunity.com/app/221410/discussions/0/882965118...

drivebyacct2 14y ago
No, I understand not distributing the games in DEB form, but what's the point of versioning an installer that then goes and downloads the latest version of the client? Just put the client in the repo...

scottlu2 14y ago

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.

throwaway64 14y ago

Steam has a package so dependancies can be satisfied easily without resorting to "install xyz beforehand", and it runs an installer into your home folder because the user has to be able to modify the games directory for many, many games on steam, because stuff like configuration, custom maps, custom models etc, is stored alongside everything else. Also steam has diff based patching (which requires accress from whoever is running the steam binary) which makes a lot more sense than how package managers operate for large packages, imagine downloading an entire 20 gig game every time there was a minor bugfix, it would be very obnoxious. Unless the design of both package managers, and how steam games store settings/etc both change radically, this really is the only workable solution. Luckily, you will still be able to share steam folders cross user, just simply give both users read/write access to the folder.

StavrosK 14y ago
This is irrelevant. They can add the Steam binary to their own PPA and update it as they update the client now. Steam will be able to do all those thing, like every single program in Linux can, while being installed as a system package. The way they're doing it now is plain unclean.
- throwaway64 14y ago
  how is it irrelivant? if people are wanting games and stuff to be distributed through the package manager, all these issues very much apply. Even the steam client package itself is something like 100megs, so it becomes painful without diff/delta patches. (steam updates a LOT)
  - StavrosK 14y ago
    I'm only talking about handling Steam updates, I agree with you on game updates. However, the Steam client can still access the user's home directory and create/access game data there, as all Linux apps do, so the current way of having Steam dump its binaries at the home dir is unclean. Pretty much the only valid point is having to update the whole thing every release, but I've never seen the Steam client download an update that was less than 75 MB.

pbhjpbhj 14y ago

So I thought I'd try and see what the score is: TF2 is 12.0 GB ... damn, that's hefty. This had better be the richest, smoothest, highest quality game; feature rich and expansive. That is about 11GB bigger than any [single] thing I've ever downloaded before. Estimated download completion time ... Christmas.