Explaining the current Steam Package build - Revision history

SigmaSquadron: Outdated

2025-04-17T17:04:32Z

Outdated

← Older revision		Revision as of 17:04, 17 April 2025
Line 1:		Line 1:
			{{outdated\|Steam's packaging has considerably changed since this article was written.}}
	This article should give insight about how steam is currently packaged and how and why it works like this. It also discusses what the problems are in packaging it and how we can approach solving them.		This article should give insight about how steam is currently packaged and how and why it works like this. It also discusses what the problems are in packaging it and how we can approach solving them.

CobaltSpace: /* chroot */ mention SteamVR issues

2024-12-01T10:16:26Z

chroot: mention SteamVR issues

← Older revision		Revision as of 10:16, 1 December 2024
Line 16:		Line 16:
	** this method would allow us to have binaries in the expected paths without disrupting the system.		** this method would allow us to have binaries in the expected paths without disrupting the system.
	** Steam itself, as well as Valve games and perhaps others like to checksum their executables, so patching does not work.		** Steam itself, as well as Valve games and perhaps others like to checksum their executables, so patching does not work.
	* Cons: Performance might suffer from this, but we are not sure.		* Cons:
			** Performance might suffer from this, but we are not sure.
			** Kernel patch is required for SteamVR asynchronous reprojection.<ref>https://lvra.gitlab.io/docs/distros/nixos/#steamvr</ref><ref>https://github.com/NixOS/nixpkgs/issues/217119</ref>

	=== Link bash to /bin and glibc/lib to /lib and be happy ===		=== Link bash to /bin and glibc/lib to /lib and be happy ===

Sen: /* chroot */ made more formal

2024-04-07T05:30:08Z

chroot: made more formal

← Older revision		Revision as of 05:30, 7 April 2024
Line 14:		Line 14:
	This is the current approach, documented here: http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html		This is the current approach, documented here: http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html
	* Pros:		* Pros:
	** it would allow us to have binaries in the expected paths without disrupting the system		** this method would allow us to have binaries in the expected paths without disrupting the system.
	** Steam itself, as well as Valve games and perhaps others like to checksum their executables, so patching does not work		** Steam itself, as well as Valve games and perhaps others like to checksum their executables, so patching does not work.
	* Cons: ~~performance?~~		* Cons: Performance might suffer from this, but we are not sure.

	=== Link bash to /bin and glibc/lib to /lib and be happy ===		=== Link bash to /bin and glibc/lib to /lib and be happy ===

Sen: /* Nix problems and constraints */ Improves clarity in the "Nix problems and constraints" section and removes first-person perspective

2024-04-07T05:24:35Z

Nix problems and constraints: Improves clarity in the "Nix problems and constraints" section and removes first-person perspective

← Older revision		Revision as of 05:24, 7 April 2024
Line 5:		Line 5:

	== Nix problems and constraints ==		== Nix problems and constraints ==
	* We don't have /bin/bash and many scripts point there. Similarly for /usr/bin/python, for some functionality.		* We don't have <code>/bin/bash</code> and many scripts point there. Similarly for <code>/usr/bin/python</code>, for some functionality.
	* We don't have the dynamic loader in /lib		* We don't have the dynamic loader in <code>/lib</code>
	* The steam.sh script in $HOME could not be patched last ~~I tried~~, as it is checked and rewritten by ~~steam~~		* The <code>steam.sh</code> script in <code>$HOME</code> could not be patched the last time an attempt was made, as it is always checked and rewritten by the Steam client.
	* The steam binary cannot be patched, ~~it's~~ also checked		* The <code>steam</code> binary cannot be patched, as this is also checked by the Steam client.

	== Approaches ==		== Approaches ==

imported>Nix: add Software/Applications subcategory

2021-09-20T05:47:52Z

add Software/Applications subcategory

← Older revision		Revision as of 05:47, 20 September 2021
Line 40:		Line 40:
	</syntaxhighlight>		</syntaxhighlight>
	You might also need patching some scripts. That all depends on each one. You can then press play from steam and if you're lucky that'll be it!		You might also need patching some scripts. That all depends on each one. You can then press play from steam and if you're lucky that'll be it!

			[[Category:Applications]]

imported>Fab: Update naming

2020-12-15T12:47:51Z

Update naming

← Older revision		Revision as of 12:47, 15 December 2020
Line 26:		Line 26:
	* Cons: this only solves the part concerned with running steam. What about the games? We can patch some of them, but at least Team Fortress is checked and rewritten if modified		* Cons: this only solves the part concerned with running steam. What about the games? We can patch some of them, but at least Team Fortress is checked and rewritten if modified

	This is the approach that I (page) took in my ~~github~~ branch: https://github.com/cpages/nixpkgs/tree/steam		This is the approach that I (page) took in my GitHub branch: https://github.com/cpages/nixpkgs/tree/steam

	=== Intercept Steam's calls with LD_PRELOAD or the like ===		=== Intercept Steam's calls with LD_PRELOAD or the like ===

imported>HLandau: /* Description of the package */

2017-10-24T20:19:48Z

Description of the package

← Older revision		Revision as of 20:19, 24 October 2017
Line 2:		Line 2:

	== Description of the package ==		== Description of the package ==
	~~and to~~ Steam is distributed as a .deb file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called steam that in ubuntu (their target distro) would go to /usr/bin. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.		Steam is distributed as a .deb file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called steam that in ubuntu (their target distro) would go to /usr/bin. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.

	== Nix problems and constraints ==		== Nix problems and constraints ==

imported>Makefu: Created page with "This article should give insight about how steam is currently packaged and how and why it works like this. It also discusses what the problems are in packaging it and how we..."

2017-10-11T14:27:16Z

Created page with "This article should give insight about how steam is currently packaged and how and why it works like this. It also discusses what the problems are in packaging it and how we..."

New page

This article should give insight about how steam is currently packaged and how and why it works like this. It also discusses what the problems are in packaging it and how we can approach solving them.

== Description of the package ==
and to Steam is distributed as a .deb file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called steam that in ubuntu (their target distro) would go to /usr/bin. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.

== Nix problems and constraints ==
* We don't have /bin/bash and many scripts point there. Similarly for /usr/bin/python, for some functionality.
* We don't have the dynamic loader in /lib
* The steam.sh script in $HOME could not be patched last I tried, as it is checked and rewritten by steam
* The steam binary cannot be patched, it's also checked

== Approaches ==
=== chroot ===
This is the current approach, documented here: http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html
* Pros:
** it would allow us to have binaries in the expected paths without disrupting the system
** Steam itself, as well as Valve games and perhaps others like to checksum their executables, so patching does not work
* Cons: performance?

=== Link bash to /bin and glibc/lib to /lib and be happy ===
* Pros: easy, works
* Cons: not very nix-compliant

=== Workaround the scripts and launch steam directly ===
* Pros: not so hard
* Cons: this only solves the part concerned with running steam. What about the games? We can patch some of them, but at least Team Fortress is checked and rewritten if modified

This is the approach that I (page) took in my github branch: https://github.com/cpages/nixpkgs/tree/steam

=== Intercept Steam's calls with LD_PRELOAD or the like ===
* Pros: more robust
* Cons: difficult to achieve and may be broken by changes in the binary

aszlig started working in this in his branch: https://github.com/aszlig/nixpkgs/tree/steam

=== But what about the games? ===
You can install any of the games normally, but they will fail to start. From this step on, you're in the unsupported realm. Some games can be patchelfed:
<syntaxhighlight lang="bash">
patchelf --set-interpreter /path/to/ld.so game_binary (you can get the path to an x86 ld.so looking at the steam script in the store, for me /nix/store/xh0q23rgqbjfrh3zfv4jyxvcvjnxqh64-glibc-2.15.0/lib/ld-linux.so.2)
</syntaxhighlight>
You might also need patching some scripts. That all depends on each one. You can then press play from steam and if you're lucky that'll be it!