add some documentation about where to find the Nix expressions for the static

tools in nixpkgs, why we chose dietlibc for some packages and glibc for others.

svn path=/nixpkgs/trunk/; revision=4447

1 files changed, 32 insertions, 0 deletions

diff --git a/maintainers/docs/static-initial-env b/maintainers/docs/static-initial-env
new file mode 100644
index 0000000000000..024a62a311e7e
--- /dev/null
+++ b/maintainers/docs/static-initial-env
@@ -0,0 +1,32 @@
+Upgrading the standard initial environment
+
+For Nix on i686-linux we make use of an environment of statically linked
+tools (see $nixpkgs/stdenv/linux). The first version of these tools were
+compiled outside of Nix, in an impure environment. They are used as some
+magical ingredient to make everything work. To keep these tools more in
+synchronization with the rest of nixpkgs and to make porting of nixpkgs
+to other platforms easier the static versions are now also built with Nix
+and nixpkgs.
+
+The tools can be found in nixpkgs in:
+
+- shells/bash-static
+- tools/networking/curl-diet
+- tools/archivers/gnutar-diet
+- tools/compression/gzip-diet
+- tools/text/gnused-diet
+- tools/text/diffutils-diet
+- tools/text/gnupatch-diet
+- tools/misc/findutils-static
+(still missing: bzip2)
+
+Most packages are compiled with dietlibc, an alternate C library, apart
+from bash and findutils, which are statically linked to glibc. The reason
+we chose dietlibc has various reasons. First of all, curl cannot be built
+statically with glibc. If we do, we get a static binary, but it cannot resolve
+hostnames to IP addresses. glibc dynamically loads functionality at runtime
+to do resolving. When linking with dietlibc this doesn't happen.
+
+The static tools are not used as part of the input hashing (see Eelco's
+PhD thesis, paragraph 5.4.1), so changing them does not change anything and
+will not force a massive rebuild.