[Nix-dev] Re: Using nix under debian stable

Benjamin Franksen benjamin.franksen at bessy.de
Wed Oct 29 13:25:44 CET 2008


Pjotr Prins wrote:
> On Tue, Oct 28, 2008 at 04:21:45PM +0100, Benjamin Franksen wrote:
>> I am trying to evaluate using nix as deployment system on top of debian
>> gnu/linux for software we write for in-house use. Unfortunately I cannot
>> use /nix as the nix store path because I don't have root permissions on
>> the relevant machine(s). I could get our admin to create me a symlink
>> /nix to somewhere but giving me a 'real' directory (which probably means
>> a dedicated partition) would require lots of arguing. So that means I
>> cannot use pre-built binaries which makes things a bit slow... Since this
>> is a test/evaluation system only, wouldn't it make sense to relax the
>> strict no-symlink policy in such cases? It would be ideal if I could
>> configure this somewhere when building nix from source. I am willing to
>> patch the nix sources if someone could give me a hint where this check is
>> implemented.
> 
> Ask him to make a hard link. You can also do away with the
> pre-compiled packages. I find it is no problem and you can share
> precompiled binaries with other systems as long as the path is the
> same. BTW current server farm pre-compiled packages are useless if you
> are compiling against other kernel headers (like I do).

Ok, I'll be going with my special nix path and forget about the binary
packages. I found out that in order to upgrade nix via nix, I have to add

  nix = {
    storeDir = "<my-nix-path>/store";
    stateDir = "<my-nix-path>/var";
  };

to ~/.nixpkgs/config.nix. Note that passing these paths without the ""
limiters does /not/ work (because nix tries to instantiate them inside
themselves and then fails with an error message).

>> Another question w.r.t. to the nixpkgs (I am using the the current
>> version form the svn repo): I noticed that the first time I 'nix-env -i
>> some-package' nix downloads and installs linux kernel headers. Now, what
>> it installs is version 2.6.23.16, but the kernel my stuff will run under
>> is 2.6.18. I am not sure but I think this is potentially unsafe; hence I
>> have changed my nix expression to use the same kernel version as I have
>> in my host system. This doesn't make a great difference to me at the
>> moment because I have to compile everything from source anyway (see
>> above) but it could make one in the future so I am asking for your
>> opinion on this.
> 
> Add the following to ~/.nixpkgs/config.nix:
> 
> {
>   git = { svnSupport = true; guiSupport = true; }; # example
>   subversion = { perlBindings = true; };
> 
>   packageOverrides = pkgs : {
>     kernelHeaders = pkgs.kernelHeaders_2_6_18;
>   };
> }
> 
> or similar. I also use Debian stable nix-env (Nix) 0.12pre12824.

Thanks for the tip, I didn't know about ~/.nixpkgs/config.nix (it is
mentioned in the docs but not very prominently). And yes, this works for me
too, especially since I have been able to convince one of the admins to fix
our /etc/nsswitch.conf (see a previous thread).

> There is a problem compiling Nix on Debian with regard to a MAXINT -
> the gcc compiler may balk. See the fix in a posting earlier
> today.

(...which I posted, BTW ;-)

>> Yet another thought that occurred to me is: what if I forget about
>> nixpkgs and use nix /only/ for our own stuff. Can I write my own nix
>> expression and import the OS stuff (compiler tool chain, headers, etc)
>> from outside of the nix store? This would be very 'impure' of course, and
>> would limit reproducability on other machines, but it might be easier to
>> start experimenting with. Any opinions, warnings, hints?
> 
> Not easier and fraud with problems. Besides no one else benefits from your
> work. Checkout the package tree with svn into 'path' and add your stuff by
> compiling:
> 
>   nix-env -f path -i mypackage
> 
> It will lead to a rock-solid setup. I use Debian stable as a platform. All
> the regular tools I have in Nix now.

I'll take your advice and refrain from such impurity ;)

Thanks again for the help

Cheers
Ben




More information about the nix-dev mailing list