path: root/nix.conf.example

### 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 /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 /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 =