### Option `gc-keep-outputs' # # If `true', the garbage collector will keep the outputs of # non-garbage derivations. If `false' (default), outputs will be # deleted unless they are GC roots themselves (or reachable from other # roots). # # In general, outputs must be registered as roots separately. # However, even if the output of a derivation is registered as a root, # the collector will still delete store paths that are used only at # build time (e.g., the C compiler, or source tarballs downloaded from # the network). To prevent it from doing so, set this option to # `true'. #gc-keep-outputs = false ### Option `gc-keep-derivations' # # If `true' (default), the garbage collector will keep the derivations # from which non-garbage store paths were built. If `false', they # will be deleted unless explicitly registered as a root (or reachable # from other roots). # # Keeping derivation around is useful for querying and traceability # (e.g., it allows you to ask with what dependencies or options a # store path was built), so by default this option is on. Turn it off # to safe a bit of disk space (or a lot if `gc-keep-outputs' is also # turned on). #gc-keep-derivations = true ### Option `gc-reserved-space' # # This option specifies how much space should be reserved in normal # use so that the garbage collector can run succesfully. Since the # garbage collector must perform Berkeley DB transactions, it needs # some disk space for itself. However, when the disk is full, this # space is not available, so the collector would not be able to run # precisely when it is most needed. # # For this reason, when Nix is run, it allocates a file # /nix/var/nix/db/reserved of the size specified by this option. When # the garbage collector is run, this file is deleted before the # Berkeley DB environment is opened. This should give it enough room # to proceed. # # The default is "1048576" (1 MiB). #gc-reserved-space = 1048576 ### Option `env-keep-derivations' # # If `false' (default), derivations are not stored in Nix user # environments. That is, the derivation any build-time-only # dependencies may be garbage-collected. # # If `true', when you add a Nix derivation to a user environment, the # path of the derivation is stored in the user environment. Thus, the # derivation will not be garbage-collected until the user environment # generation is deleted (`nix-env --delete-generations'). To prevent # build-time-only dependencies from being collected, you should also # turn on `gc-keep-outputs'. # # The difference between this option and `gc-keep-derivations' is that # this one is `sticky': it applies to any user environment created # while this option was enabled, while `gc-keep-derivations' only # applies at the moment the garbage collector is run. #env-keep-derivations = false ### Option `build-max-jobs' # # This option defines the maximum number of jobs that Nix will try to # build in parallel. The default is 1. You should generally set it # to the number of CPUs in your system (e.g., 2 on a Athlon 64 X2). # It can be overriden using the `--max-jobs' / `-j' command line # switch. #build-max-jobs = 1 ### Option `build-max-silent-time' # # This option defines the maximum number of seconds that a builder can # go without producing any data on standard output or standard error. # This is useful (for instance in a automated build system) to catch # builds that are stuck in an infinite loop, or to catch remote builds # that are hanging due to network problems. It can be overriden using # the `--max-silent-time' command line switch. # # The value 0 means that there is no timeout. This is also the # default. # # Example: # build-max-silent-time = 600 # = 10 minutes #build-max-silent-time = 0 ### Option `build-users-group' # # This options specifies the Unix group containing the Nix build user # accounts. In multi-user Nix installations, builds should not # be performed by the Nix account since that would allow users to # arbitrarily modify the Nix store and database by supplying specially # crafted builders; and they cannot be performed by the calling user # since that would allow him/her to influence the build result. # # Therefore, if this option is non-empty and specifies a valid group, # builds will be performed under the user accounts that are a member # of the group specified here (as listed in /etc/group). Those user # accounts should not be used for any other purpose! # # Nix will never run two builds under the same user account at the # same time. This is to prevent an obvious security hole: a malicious # user writing a Nix expression that modifies the build result of a # legitimate Nix expression being built by another user. Therefore it # is good to have as many Nix build user accounts as you can spare. # (Remember: uids are cheap.) # # The build users should have permission to create files in the Nix # store, but not delete them. Therefore, /nix/store should be owned # by the Nix account, its group should be the group specified here, # and its mode should be 1775. # # If the build users group is empty, builds will be performed under # the uid of the Nix process (that is, the uid of the caller if # $NIX_REMOTE is empty, the uid under which the Nix daemon runs if # $NIX_REMOTE is `daemon', or the uid that owns the setuid nix-worker # program if $NIX_REMOTE is `slave'). Obviously, this should not be # used in multi-user settings with untrusted users. # # The default is empty. # # Example: # build-users-group = nix-builders #build-users-group = ### Option `build-use-chroot' # # If set to `true', builds will be performed in a chroot environment, # i.e., the build will be isolated from the normal file system # hierarchy and will only see the Nix store, the temporary build # directory, and the directories configured with the # `build-chroot-dirs' option (such as /proc and /dev). This is useful # to prevent undeclared dependencies on files in directories such as # /usr/bin. # # The use of a chroot requires that Nix is run as root (but you can # still use the "build users" feature to perform builds under # different users than root). Currently, chroot builds only work on # Linux because Nix uses "bind mounts" to make the Nix store and other # directories available inside the chroot. # # The default is `false'. # # Example: # build-use-chroot = true #build-use-chroot = false ### Option `build-chroot-dirs' # # When builds are performed in a chroot environment, Nix will mount # (using `mount --bind' on Linux) some directories from the normal # file system hierarchy inside the chroot. These are the Nix store, # the temporary build directory (usually /tmp/nix-<pid>-<number>) and # the directories listed here. The default is "/dev /dev/pts /proc". # Files in /dev (such as /dev/null) are needed by many builds, and # some files in /proc may also be needed occasionally. # # Example: # build-use-chroot = /dev /proc /bin #build-chroot-dirs = /dev /dev/pts /proc ### Option `system' # # This option specifies the canonical Nix system name of the current # installation, such as `i686-linux' or `powerpc-darwin'. Nix can # only build derivations whose `system' attribute equals the value # specified here. In general, it never makes sense to modify this # value from its default, since you can use it to `lie' about the # platform you are building on (e.g., perform a Mac OS build on a # Linux machine; the result would obviously be wrong). It only makes # sense if the Nix binaries can run on multiple platforms, e.g., # `universal binaries' that run on `powerpc-darwin' and `i686-darwin'. # # It defaults to the canonical Nix system name detected by `configure' # at build time. # # Example: # system = i686-darwin #system =