Some points: - nix-collect-garbage will collect garbage of the builtins /nix/store path, right? - you're case 2 (recovery) could be replaced by introducing a salt such as passing a dummy var to a derivation everything depends on. I agree that there are use cases which this doesn't catch such as other databases (eg change from filesystem based to sqlite) or eventually even debug filesystem issues. Its trivial to mount /dev/X to /nix-test/{var,store}
- testing is only important if there are use cases? And several people have used nixpkgs in their $HOME directory in the past so it does matter Question: Would user mode linux be an option instead? I mean if you use user mode linux you can reuse hydra binaries. Using user mode linux you can run most test cases on virtualized hardware. The current qemu/kvm based test cases require a dedicated machine. - About breaking: Yes it will break - but its also easy to fix in most cases. And most cases can be caught by a simple grep command. So we could even create a pro-commit hook or check. > 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. Can you provide more details? I still don't understand. I mean do you want to use /nix/root-store/* which may contain passwords and which root may only access? /nix/store/* for the rest of the users? What happens if you start any service which changes user id and tries to access its libraries? So which kind of data do you want to protect? Looks like we should find a solution. > 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? What do you mean? /nix/marc-store/ /nix/shea-store/ ? I think the strength about nix is sharing. You can share. The *branding* is what other distros have to do (duplicate everything within a chroot). Do you have this is mind or is it just a "could be done idea nobody will ever actually use?" It doesn't matter. I'm for the feature because it doesn't hurt much and recovery might be a valid point in very rare cases - and then you're glad that it exists even though I agree that the common use case does not require it. Marc Weber _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev