>I've been thinking about creating a nixpkgs branch to find and eliminate >some of the remaining impurities in the Linux stdenv. Before I get >started, I wanted to poll the list with a few questions that will shape >how I go about things. > >1. What impurities does the current stdenv have? I can think of three >off of the top of my head: timestamps in files, kernel version (e.g. via >uname), and /bin/sh.
Obviously, we should only care about builds with all paranoid options (like chroot) on. I am not sure that on non-NixOS systems we don't get entire /bin/ in chroot... Fortunately, most of things fail because of missing /lib/. Something that checks existence of /bin/rm still can fail. Processor having or not having some features (think MPlayer MMX hand-optimized loops in assembler language) - no idea if it is possible to fight that. We have _deliberate_ optional impurity about parallelBuilds. You didn't notice it because it is a secret feature with double opt-in (you need to enable it on command line, and then for individual packages). If something tries to do a networking test, it can be in for a lot of fun - for example, a random port can be occupied or not on host. This seems to require something on the level of lxc to prevent. CLisp has network module tests by default. We pass /dev/ inside chroot as-is. There are many readable sources of disaster there. I am not sure foozjs doesn't have a mode where it tries to detect your printer during installation. Of course, resource exhaustion is another set of questions... >2. What kind of testing should I set up to see that my changes actually >remove impurities? For most of impurities it is trivial to implement special builder It could get the information you want to be inaccessible and write it to output. >3. When might it be desirable to have impurities? I can think of three >cases: When knowledge of the performance of the system could potentially >speed up a build (e.g. knowing how many cores the CPU has for parallel >building), when knowledge of the performance of the system is necessary >for a test (e.g. checking that running a certain tool completes its task >in the right amount of time), and when a build would otherwise fail. My >current view is that the first two cases are OK as long as the >impurities (preferably provably) don't affect the output (think >unsafePerformIO), and that the for the third case we should attempt to >fix the build system in question if possible and should explicitly >include whatever system information is being accessed as a dependency if >not. Ideally our build system would give us ways to purposely allow >impurities when they are of the first two types, such as the >enableParallelBuilding variable the generic builder currently recognizes. In the really really ideal world I would like first kind of impurity to be fully manageable from Nix command line and the second kind to be split off in a separate -tests package with fixed output (namely: empty). Fixed-output impurities are OK, I guess. _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev