Hi, Thanks for having a look at this!
On Thursday 06 November 2014 13:17:57 Wout Mertens wrote: > On Tue Oct 28 2014 at 10:15:03 PM Andreas Herrmann <[email protected]> > wrote: > > I would like to ask you guys to have a look at this script and tell me > > what you think of it. Do you think it could be valuable to add something > > like this as an automated installer to the official Nix distribution > > similar to the one for single-user mode? > > Definitely, although I think it would be best to have it as script to run > after one already installed Nix. That way, existing installs can just be > converted. That is an interesting idea. The current single user install script installs nix for a non-root user. How would you go about transforming such an installation to a multi-user nix? Just chown it to root, or are there more subtle issues to think about? (In particular the default-profile...) > I did come up with a few specific questions during the course of this: > > > > * The nix-daemon is not daemonizing itself. Why is that? > > On debian this is not a problem thanks to `start-stop-daemon`. On > > CentOS I ended up writing a wrapper script. > > Self-daemonizing daemons are not so wonderful. It's nicer to have a > watchdog daemon doing the background running and logging, and it makes the > program a little simpler. > > Besides, you can daemonize anything from the shell simply by closing stdin > and running in the background: > > $ run_as_daemon >$LOGFILE 2>&1 <&- & echo $! > $PIDFILE > > The shell does the right thing, disassociating the child when it exits etc. Nice, I had forgotten about `<&-`. I should modify my wrapper accordingly. The reason I chose a wrapper instead of doing the above right in the init-script is, that CentOS offers a few standard shell functions which do things like print that nice green `[ OK ]` and such. > * The chroot build feature seems to require a statically linked bash. > > Compiling this (plus some dependencies) can take quite some time. Do > > you think a static bash would be a > > viable addition to `nixpkgs`? > > Not really - you just need to make sure all the libraries are in the > chroot. I would think that it just works on Linux, where everything is > linked only to /nix/store (unless the build got tainted). On Darwin the > stdenv isn't pure yet but even then the required libraries can be copied. On Thursday 06 November 2014 14:41:25 Peter Simons wrote: > it "just works" on NixOS, because the system auto-generates an appropriate > /etc/nix/nix.conf file that includes all bits required by "bash" into the > chroot environment. > [...] > On other Linux systems, this needs to be configured manually. So, coming back to this. Do you think the static bash would be a good package to add? On Thursday 06 November 2014 13:17:57 Wout Mertens wrote: > Note that the chroot isn't really required to build things and in its > current form it slows down builds. See > https://github.com/NixOS/nix/issues/179 . As I understand this the build seems to be slowed down by all the bind mounts. But, shouldn't a non-trivial package spent far more time on actual building than on bind mounting? I just think that the benefit in purity due to chroot outweights the cost of the bind mount. > * Is there a way to add globally visible package overrides but still use > > the nix-channel? > > Absolutely, that's what packageOverrides in the nixpkgs configuration is > for. If a binary build is available, it will be used, otherwise you'll do > the build locally. Thanks, then let me follow up on this: How can I configure global packageOverrides that will be visible to all users; yet, still allow them to add their own packageOverrides on top of that? I.e. where does the global equivalent of `~/.nixpkgs/config.nix` go on a non-NixOS multi-user Nix? Best, Andreas _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
