[Nix-dev] Dealing with non-Bash /bin/sh on non-NixOS

[Michael Raskin]

>Hi Michael,
>
>Michael Raskin <7c6f434c at mail.ru> skribis:
>
>> I have some basic-chroot.nix, which is what basics I need to do Nix 
>> builds and look at simple problems comfortably.
>>
>> It is literally:
>>
>> let nixpkgs = import <nixpkgs> {}; in with nixpkgs; 
>>   symlinkJoin "chroot-system" [
>>     nixUnstable openssl (glibcLocales.override {allLocales = true;})
>>     rlwrap gcc zlib patchelf coreutils stdenv bashInteractive su gnugrep
>>     gnused less findutils curl wget utillinuxCurses subversion openssh
>>     gzip vim file strace lsof 
>>   ]
>>
>> I build it as /var/chroot-env
>>
>> When I need to do a rebuild that includes some local work, I do
>>
>> /etc/nixos/configurations/misc/raskin/misc-scripts/special-chroot \
>>      /var/nix-chroot /root root usr-only /var/chroot-env
>
>Wow, that seems a little bit too sophisticated for a first-time user.
>;-)

Well, you put your situation so that I thought you also wanted a 
solution that could be used in the interim.

Doing the Right Things requires some discussion of requirements and
some time to implement...

>Ideally, I’d like a solution that Just Works for anyone trying out Nix.
>
>I was thinking that, instead of just bind-mounting /bin, we could have
>at least a nix-daemon option that would allow the host code to specify
>which file /bin/sh should point to.  Even better would be to have an
>additional ‘derivation’ parameter.

What we could need:

1) It is nice to keep ability to bind-mount directories from the real 
system into chroot. Use case: I have some repositories mirrored and 
don't want to clone entire repositories into store without need.

2) NixPkgs should be able to be specify chroot-compatible setting set
without any manual configuration.

3) Purity says that taking things from external paths should only be
allowed in fixed-output derivations, but I currently have some cases
where corners are cut with checkouts (and maybe some other people do).
	Still, having a consistent model here would be a plus.

So, I guess there would be a configuration option (marked as dangerous
and/or impure) to override what is taken from external environment for 
a normal chroot build (ideally, nothing — maybe it is possible to use
even fake proc?). There would be a derivation option to say what to put
into chroot (I guess it will usually be outPath of some derivation). 
There would be a configuration option to specify whether fixed-output
builds are in chroot, and an option to specify what paths from external
system are needed in this case.

/bin/sh would appear because of derivation parameters, I guess.

>Eelco: what do you think?