[Nix-dev] [Nix-commits] SVN commit: nix - r30127 - in nixos/trunk/modules: config installer/cd-dvd installer/generations-dir installer/tools installer/tools/nixos-deploy-network misc security services/misc services/monito...

[Shea Levy]

On 10/30/11 6:49 PM, Eelco Dolstra wrote:
> I'm pretty sure that the cause of this is this line:
>
>> -  config.nixpkgs.config.nix = { storeDir = /nix/store; stateDir = /nix/var; };
> This should be:
>
>    config.nixpkgs.config.nix =
>      { storeDir = "/nix/store"; stateDir = "/nix/var";};
>
> Note the quotes.  Otherwise, the entire /nix/store and /nix/var will be read as
> a dependency of the generated config files that refer to it.

*facepalm*. I didn't notice because my configuration.nix that overrode 
this used the quotes. Stupid, sorry.

> On the other hand, is it really necessary to make this configurable?  Clearly
> people may want to use Nix with non-standard prefixes, but in NixOS we should be
> able to assume that we can use /nix/store and /nix/var.

I can think of several reasons for a NixOS with non-standard store 
prefixes (the first two are things I've actually encountered, the rest I 
thought of while composing this reply):

1. To provide a platform for thorough testing to assure that nixpkgs 
doesn't make any assumptions about /nix/store. All of my Linux boxen are 
NixOS, and the best way I have to stress-test nixpkgs as a developer is 
to try to use the packages it builds for my other work, so I need a 
NixOS with a non-standard store to really test it.

2. Recovery from a broken store without significant downtime. I have a 
server that has a few live paths that fail nix-store --verify 
--check-contents, and worse it has built several whole systems for a 
laptop with several dozen verify-failing paths using build-remotes, 
which copies over store paths and asserts them as valid on the other 
machine. I'm only rarely in the same location as the server and the 
downtime involved in booting a livecd, nuking the store, and rebuilding 
would be prohibitive anyway. Ideally I'd just rebuild the system into an 
alternative store path, continue using the server while the rebuild 
proceeds, reboot into the new system (maybe 1 minute of downtime), nuke 
the original store and rebuild into it, and reboot again.

3. Sharing a store with a system that can't use /nix/store for whatever 
reason (permissions or whatever).

4. Using a remote builder that is also a remote builder for a system 
that can't use /nix/store.

5. Having multiple stores on a single system, each with paths built 
using NixOS. Applications of multiple stores might include private 
stores for sensitive configurations, having different stores with 
different levels of trust (e.g. one store that only contains 
locally-built packages that takes precedence in $PATH and such, but 
another that uses substitutors so you can get stuff done while you're 
waiting for your local build to finish), allowing non-privileged users 
to use their own substitutors, etc.

6. Branding. Not a big concern right now, I know, but if NixOS gets big 
(fingers crossed!) and others want to rebrand it, why not let them use a 
custom-branded store path?

> Also, without automated tests, this feature will inevitably suffer from bitrot.
>   (People will make future changes that assume /nix/store and /nix/var.)
>

Sure, and people can write pkgs.linuxPackages instead of 
config.boot.kernelPackages, and people can use /nix/store instead of 
$NIX_STORE in nixpkgs (they do, a lot!). I'd be glad to write some 
automated tests, but this isn't exactly specific to this option.

Cheers,
Shea