Merge pull request #106845 from AndersonTorres/wip-documentation

doc/builders/fetchers.chapter.md

@@ -0,0 +1,70 @@
+# Fetchers {#chap-pkgs-fetchers}
+
+When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way.
+
+The two fetcher primitives are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
+
+```nix
+{ stdenv, fetchurl }:
+
+stdenv.mkDerivation {
+  name = "hello";
+  src = fetchurl {
+    url = "http://www.example.org/hello.tar.gz";
+    sha256 = "1111111111111111111111111111111111111111111111111111";
+  };
+}
+```
+
+The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
+
+`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
+
+
+Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward nambes based on the name of the command used with the VCS system. Because they give you a working repository, they act most like `fetchzip`.
+
+## `fetchsvn`
+
+Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha256`.
+
+## `fetchgit`
+
+Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
+
+## `fetchfossil`
+
+Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `sha256`.
+
+## `fetchcvs`
+
+Used with CVS. Expects `cvsRoot`, `tag`, and `sha256`.
+
+## `fetchhg`
+
+Used with Mercurial. Expects `url`, `rev`, and `sha256`.
+
+A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
+
+## `fetchFromGitHub`
+
+`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
+
+## `fetchFromGitLab`
+
+This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
+
+## `fetchFromGitiles`
+
+This is used with Gitiles repositories. The arguments expected are similar to fetchgit.
+
+## `fetchFromBitbucket`
+
+This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
+
+## `fetchFromSavannah`
+
+This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
+
+## `fetchFromRepoOrCz`
+
+This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.

doc/builders/packages/index.xml

@@ -14,7 +14,7 @@
  <xi:include href="ibus.xml" />
  <xi:include href="kakoune.section.xml" />
  <xi:include href="linux.section.xml" />
- <xi:include href="locales.xml" />
+ <xi:include href="locales.section.xml" />
  <xi:include href="nginx.section.xml" />
  <xi:include href="opengl.section.xml" />
  <xi:include href="shell-helpers.section.xml" />

doc/builders/packages/locales.section.md

@@ -0,0 +1,5 @@
+# Locales {#locales}
+
+To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
+
+On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.

doc/builders/special.xml

@@ -5,6 +5,6 @@
  <para>
   This chapter describes several special builders.
  </para>
- <xi:include href="special/fhs-environments.xml" />
- <xi:include href="special/mkshell.xml" />
+ <xi:include href="special/fhs-environments.section.xml" />
+ <xi:include href="special/mkshell.section.xml" />
 </chapter>

doc/builders/special/fhs-environments.section.md

@@ -0,0 +1,45 @@
+# buildFHSUserEnv {#sec-fhs-environments}
+
+`buildFHSUserEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
+
+- `name`
+        Environment name.
+- `targetPkgs`
+        Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
+- `multiPkgs`
+        Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
+- `extraBuildCommands`
+        Additional commands to be executed for finalizing the directory structure.
+- `extraBuildCommandsMulti`
+        Like `extraBuildCommands`, but executed only on multilib architectures.
+- `extraOutputsToInstall`
+        Additional derivation outputs to be linked for both target and multi-architecture packages.
+- `extraInstallCommands`
+        Additional commands to be executed for finalizing the derivation with runner script.
+- `runScript`
+        A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to `bash`.
+
+One can create a simple environment using a `shell.nix` like that:
+
+```nix
+{ pkgs ? import <nixpkgs> {} }:
+
+(pkgs.buildFHSUserEnv {
+  name = "simple-x11-env";
+  targetPkgs = pkgs: (with pkgs;
+    [ udev
+      alsaLib
+    ]) ++ (with pkgs.xorg;
+    [ libX11
+      libXcursor
+      libXrandr
+    ]);
+  multiPkgs = pkgs: (with pkgs;
+    [ udev
+      alsaLib
+    ]);
+  runScript = "bash";
+}).env
+```
+
+Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported.