* Added `build-users-group', the group under which builds are to be performed. * Check that /nix/store has 1775 permission and is owner by the build-users-group.
		
			
				
	
	
		
			138 lines
		
	
	
	
		
			5.3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			138 lines
		
	
	
	
		
			5.3 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| ### 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-users'
 | |
| #
 | |
| # This option contains a list of user names under which Nix can
 | |
| # execute builds.  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.
 | |
| #
 | |
| # Thus this list should contain a number of `special' user accounts
 | |
| # created specifically for Nix, e.g., `nix-builder-1',
 | |
| # `nix-builder-2', and so on.  The more users the better, since at
 | |
| # most a number of builds equal to the number of build users can be
 | |
| # running simultaneously.
 | |
| #
 | |
| # If this list is empty, builds will be performed under the Nix
 | |
| # account (that is, the uid under which the Nix daemon runs, or that
 | |
| # owns the setuid nix-worker program).
 | |
| #
 | |
| # Example:
 | |
| #   build-users = nix-builder-1 nix-builder-2 nix-builder-3
 | |
| #build-users =
 | |
| 
 | |
| 
 | |
| ### Option `build-users-group'
 | |
| #
 | |
| # If `build-users' is used, then this option specifies the group ID
 | |
| # (gid) under which each build is to be performed.  This group should
 | |
| # have permission to create files in the Nix store, but not delete
 | |
| # them.  I.e., /nix/store should be owned by the Nix account, its
 | |
| # group should be the group specified here, and its mode should be
 | |
| # 1775.
 | |
| #
 | |
| # The default is `nix'.
 | |
| #
 | |
| # Example:
 | |
| #   build-users-group = nix
 | |
| #build-users-group =
 | |
| 
 | |
| 
 | |
| ### 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 =
 |