This is not a good idea.
More often than not users set aside a root partition of a fairly limited size and use the remaining space for their home-partition.
Your suggestion would necessitate a rather large root-partition, thus making it more complicated to use, less flexible and much more prone to user error. (I can imagine a support nightmare of confused users who fail to install a game because the root-partition is filled up, but the home-partition shows ample free space. Not to speak of the system breakage that usually is caused by a full root-partition.)
Additional critical problems when using steam as an 'additional' package-manager are:
It's certainly not an easy problem to solve, but the current solution of storing everything in /home is not acceptable.
The most obvious solution to the first problem is store the games in /usr/local/games and make a new partition for /usr/local (widely accepted). The steam binaries in /opt wouldn't take up a lot of room on their own if the games were separated, but if that is an issue, just move /opt to its own partition as well (again, very widely accepted). You could even make a semi-plausible argument to store the games in /var/opt/valve/steam, which /var is another widely accepted option for partition separation.
Second, yes, application package manager conflicts with system package managers are a real possibility, but it can be minimized. There are quite a few working instances in the wild already... what's wrong with one more?
Third, while I think it's semi-obtuse to distrust closed source applications just because they're closed, there is some merit there. To address this concern, you could simply store the games in a parent folder that the group gives access to and thus removing the single elevation during installation of a game. In fact, this might be preferred to further eliminate any conflicts between the application and system package manager.
Compromises will have to be made, but again... /home is not a place to install software and when you're talking about games which can be shared among accounts, /home is an even worse choice.
Why is it not acceptable to store game-installations in /home?
Package Management:
Trusting closed source:
Compromises:
If FHS is so antiquated, maybe you should fight the good fight with LSB and have it deprecated; however, until that happens, installing Steam to /home is not a decent compromise because it completely violates the FHS and LSB compliance. /home is meant for data specific to a user that can be shared or is as architecture independent as possible. In other words, a roaming profile.
No, Cabal will by default install globally, but you can install it to your home profile by specifying a user. Having the freedom to do so is arguably not wrong, but in the case of Steam where you must install to /home, it's wrong.
You don't think there is much sharing of a single desktop computer? Well, might as well remove all profile support then! Come on... Yes, you can set the location of where Steam stores games, now, but the fundamental issue of having Steam install to /home is still the main violation.
Your argument that OSS is trustworthy by default is ignorant. First, I highly doubt that you or most others even check the OSS code that you installed to satisfy your concerns about security. Second, if you didn't, you're trusting someone or something by default to certify it's safe. CSS is no different except that instead of having the freedom to check, you must trust or don't install. Either way, Steam is not an application that will ever find its way onto a system that requires absolute security, even if it never required elevation, but I have already outlined a way to minimize elevation concerns to the point where it's just as safe as creating a user with pinpoint access, which is a tactic lots of software uses.
I agree that an application manager shouldn't meddle any more than necessary, but on a system where 95% of the files / folders are categorized as 'system' based, it's virtually impossible. Sure, it shouldn't be a justification, which is exactly why I said you could setup a steam folder, give the steam group access to that folder only, and minimize all issues.
Where did you read that it would violate the LSB/FHS to install application inside of /home?
If you run cabal as a user the default is "user-install: True", that means installation in $HOME/.cabal. It would make sense though, if run as root to default to system-wide install, I guess that is what you tested.
OSS is not trustworthy by default, that was the point, that you do not need to trust anyone if you read the code.
And when you don't read it, there will be users that do, sort of community based trust instead of trusting a corporation. At least when the user-base is big enough.
Your suggestion makes it more complicated without adding benefit. Sharing of game-files can already be achieved with Steam Library Folders and I cannot find any indication that storing game-files somewhere in /home is bad in any way whatsoever. Even if it would violate the FHS, which as far as I know, it does not.
My suggestion doesn't make things any more complicated than it already was. The standard was approved ages ago and remains in place. The complicated nature springs from the fact that Valve is not compliant with the standard.
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEFILESYSTEM
If you read the FHS and understood its intended purpose, the nature of /home should be quite clear. /home is not suitable for application installation, despite not saying it verboten.
For starters, the idea that you'd want to install software into a user's specific directory is very limiting because no other user would be able to use it. Even Windows understands that and doesn't do it. The only way it'd be acceptable was if the software was completely specific to that user (set of bash scripts, etc) and in no way of interest to any other. The fact that Steam allows for multiple users, is proof enough that Steam is not suitable to default its installation to /home.
Second, there's absolutely no reason to have /opt if the FHS standard advocated installing software to /home.
I will not argue this any further. It's quite clear that Valve and Steam are violating the FHS and it really needs to be resolved. The FHS and LSB compliance are not optional...
If there is no mention of any restriction for /home in the spec it is not a violation.
It might be in violation with what you think the FHS means, but that is irrelevant.
"it completely violates the FHS and LSB compliance."
It isn't violating anything. It isn't complying with it, but last I checked, the Steam client wasn't trying to satisfy those in the first place, and it doesn't need to. On that note, it does aim to satisfy (and correctly implement) a variety of the Freedesktop XDG standards which cover the case of desktop applications putting lots of stuff under /home. Among these we have the base directory standard (which generally leads to "big files like a bunch of downloaded data files go in ~/.local/share/yourapp"), and various standards which allow us to put application launchers and icons under ~/.local/share/applications and ~/.local/share/icons, respectively.
If you can come up with a suggestion that doesn't step on a package system's toes (read: doesn't go anywhere near /usr/ without asking nicely, first, and even then nowhere above /usr/local/), I think that might be useful. One thing to keep in mind is Steam users often enjoy being able to write to the Steam folder directly, without too much trouble. This is useful for things like game mods, for example.
"It isn't violating anything. It isn't complying with it"
Violating and non-compliance are synonyms. It's impossible to fail to comply with an agreement or standard and then argue that the agreement or standard wasn't violated.
It could be argued that Valve does not have a direct responsibility to comply with the FHS in regards to Steam; however, if Valve wants to claim they support a distribution (ubuntu) which does support the FHS and LSB, then they should make the effort to comply.
Freedesktop XDG was proposed to 'clean-up' the /home directories. In other words, instead of having a ton of stray 'dot' folders like .gnome/ and .gnome2/, there would only be 'dot' folders broken down into a classification, like .config/, .local/, etc. It is not a solution that circumvents the FHS or LSB by redefining where users should store application data. In fact $XDG_DATA_DIRS defaults to /usr/local/share/:/usr/share/.
The problem is that linux users are either ignorant to what the FHS is or they have always found it easier to disregard it. In fact, the only few times a user generally complies with the FHS is when they're installing something via the default package manager, and that is only because compliance is not a choice.
If you'd like, forget the FHS for a minute. Steam is by classification a system wide, multi-user application, and thereby defaulting installation into a specific user's /home directory, in which no other user can access, is not the best choice. If Valve want to give the user the option to install into their /home, more power to them, but the most appropriate default installation location of Steam is outside /home.
The FHS states no restriction about what should go into /home, it recommends other places for certain things, that might be true.
Hence steam does not comply with it(, because it does not follow the recommendation), but does definitely not violate the FHS(, because it does not do anything 'forbidden'). That should be about the difference of the two words I guess.
Also who cares what ubuntu is supporting? They also support another display-server that no-one else cares about.
Supporting Ubuntu just means, that they make sure that it runs on Ubuntu, not a bit more.
Or would you suggest that all software should always try to support the same things as the OS they are running on? Like all Windows games should use Windows Live Gaming? Or all Mac games should support saving all their stuff in iCloud? That argument makes not a lot of sense.
Multi-User Linux desktop-systems are a minority and steam can be used with with a shared library-folder if someone really wants to set that up. No problem there.
Going with what most users want to do and have (big home partitions) the current default is the most sane thing to do.
Whether you or anyone else choose to adhere to the FHS standard on your end does not matter. The FHS is inherent to unix and linux. It's a fundamental function of their existence as a kernel and the OS as a whole.
Valve is not in compliance with the FHS because it is installing a system-wide, multi-user, third-party software directly into a user's /home. If the user chooses to do that, fine... but it is a total violation of the FHS for Valve to do so with Steam by default.
The wording of the FHS may appear as a suggestion instead of a mandate, but it does so for a reason. It's obviously not a mandatory restriction because the authors of the FHS knew it wasn't a black and white situation. Some times there is good reason to install software to /home, but Steam is not one of them. I have pointed out that fact and the justifications several times...
Your entire argument is that because the mass public choose to use Linux a certain way, ie. create a large /home partition and install everything into it, Valve should keep Steam installed to the /home partition. Well, I'm sorry, but that is about as ridiculous as saying the world shouldn't have standards because no one follows them in the first place.
You want to make a solution the default that won't benefit the majority of users, that is a bit silly.
The FHS benefits users, because distros and their package-management adhere to it, which is good.
Steam is neither a Linux Distribution nor a distributions package-management.
Again, you claim that my solution wouldn't benefit the majority of users, but who is that majority? Right... individuals that are ignorant of the FHS either by choice or naivety. Adherence to a standard shouldn't be about majority. It should be about the reasons for which the standard was put in place.
Once again, forget about the FHS and Linux for a minute. Having the installation of a system-wide, multi-user, third-party application default to a user's personal folder is absolutely ridiculous. No other user could access it without being given special permissions, or they'd have to install it for themselves, which wastes more space. If another user was given access, their config and data would be stored in the first user's personal folder, making it very easy to lose other user's data. Consider the possibility of user A deleting Steam, which would then wipe out user B's data... or vice versa.
Google Chrome isn't a a Linux Distribution or a package manager either, but by your logic, Google must have been down right bonkers to choose the default installation path of /opt/google-chrome for their browser. I'm quite certain they have more users within the linux community, so it must be causing a world of hurt for everyone... not.
Just a friendly reminder; this isn't a forum. While the discussion is valid, you've both made your points and counterpoints. At this stage of the discussion, you're both just rehashing things. Having input from others would be useful.
Something else to consider would be how changing it over should affect current installations (create an opt-in script to relocate your installation/library, allow it to remain and require a reinstall for new location, etc.).
Is there really a need for a script? For example, could the self-update engine of Steam identify the installation as non-compliant or compliant and update appropriately? A quick check would be to locate a lib file in /usr/lib or some other file / location that a user wouldn't normally create.
If Valve wants to create a script to enable users to adopt the compliant method, it could be useful, but I honestly don't see many people going through the trouble. Most will wait until they have to reinstall...
With Steam Family Sharing around, Steam for Linux should really try to respect FHS.
Storing Steam files in each session makes it complicated to share games between sessions...
Just to post a single-user usecase for moving Steam outside of /home:
I have a 60GB SSD for / and /home, specifically to boot quickly and get to my data quickly. Steam is too big to fit either in /usr/bin or /home. If it was in /opt as a third-party apt, or in /games, I could easily mount that on a HDD with TB's of space. Now, I'm going to have to do a symlink kludge for every game, or uninstall HL2 Episode 1 to play Episode 2.
This is probably a fairly common use case for most people, as mounting /home on your SSD is a good way to speed things up.
Aside from all this, not putting system-wide data in /home/username seems like a fairly decent thing to do. Also, feel free to make this change something you will have to reinstall for.
This was closed as https://github.com/ValveSoftware/steam-for-linux/issues?q=is%3Aissue+is%3Aclosed+archived%3Afalse+reason%3Acompleted+sort%3Aupdated-desc by @mwpow3ll at https://github.com/ValveSoftware/steam-for-linux/issues/2580#event-3375219201. Does that mean that the suggestions have been implemented? If not, this should be closed as invalid/unplanned instead.
https://github.com/ValveSoftware/steam-for-linux/issues/2580#issuecomment-20167502
However, I wholeheartedly agree with @mwpow3ll – multi-user systems with not much storage space using family sharing (a common scenario for poor families) are absolutely demolished by Steam.
By the way, @mwpow3ll, regarding https://github.com/ValveSoftware/steam-for-linux/issues/2580#issue-15313173
- /home//.steam would contain a few client preferences or config files and a database of the games the user has installed which also tracks the DLCs, mods, etc they have access to.
- /home//. would be the location where games store their save games, screenshots, etc.
you should use $HOME instead of /home wherever possible due to $HOME being able to be mounted at an arbitrary mount-point. it helps everyone.
The other issue discussing this problem was closed, but I didn't see a reason given and this really needs a solution. Here's my suggestion:
The installer would require elevation to create a steam group, make the current user a member of said group (steam), install the client in /opt/valve/steam, and set the group ownership of /opt/valve/steam and /var/opt/valve/steam. This way, the steam client can be run at the user level.
If the steam client wants to install a game it would request elevation, install the game, and set all created root folders, along with the binary link, to the group ownership of steam. That way, the steam client could remove a game, without elevation, provided the user is a member of the steam group.
Finally, if a user wanted to back-up their games, the steam client could simply tar the /usr/*/ locations. If the user chooses to include their specific data in the back-up, the steam client could tar that as well.
This solution really also depends on Valve guiding the game developers to embrace the FHS when porting.