EmilyandQyriad
1fa9c4d55f
This makes the paths more nondeterministic, but more reliably unique, and lets us remove the retry loop. Note that this adds random entropy to the build directory visible inside derivations on Darwin and unsandboxed Linux. It was already non‐deterministic in the presence of concurrent builds and similar, but now we can reliably expect it to be different every time. On the whole I think that’s a good thing, as it is impossible to ensure a single consistent build directory and derivation outputs should not depend on it. Package reproducibility isn’t great on Darwin to begin with, though, and the reproducibility bugs this will turn up in packages will be more urgent to fix than when the build directory was mostly consistent. A quick survey of my local store shows that many C, C++, and Rust binaries contain build directory references, likely due to use of `__FILE__` and its equivalents; non‐binary offenders include: * Install logs included in the Rust and Cargo bootstrap compilers * Example errors in the Rust documentation referencing build paths * Configuration information installed with CPython itself * Python 2 metadata from resholve’s closure * Cython metadata * Generated headers in Facebook libraries referencing source paths * Generated CMake files in Facebook libraries referencing source paths I haven’t built that much in this store since the last GC, so this is probably only a small sample of the problems across the tree. These are all instances of <https://reproducible-builds.org/docs/build-path/>, though, and should probably just be treated as general reproducibility bugs outside of contexts like the Linux sandbox where we can normalize them away entirely. I have implemented away build directory paths for C/C++, applied some additional fixes for non‐`__FILE__`‐related issues in binaries from ATF and LLVM, and fixed the derivation bug causing the CPython 3 issue, and will work on upstreaming these changes. Rust is working on the problem upstream, with some temporary workarounds we can potentially apply in Nixpkgs for now. The rest will require some distributed effort. Change-Id: I6a6a69645b4915c56c0fdef904aa81684e4136c6
Lix
Lix is an implementation of Nix, a powerful package management system for Linux and other Unix systems that makes package management reliable and reproducible.
Read more about us at https://lix.systems.
Installation
On Linux and macOS the easiest way to install Lix is to run the following shell command (as a user other than root):
$ curl -sSf -L https://install.lix.systems/lix | sh -s -- install
For systems that already have a Nix implementation installed, such as NixOS systems, read our install page
Building And Developing
See our Hacking guide in our manual for instruction on how to set up a development environment and build Lix from source.
Additional Resources
- The Lix reference manual:
- Our wiki
- Matrix - #space:lix.systems
License
Lix is released under LGPL-2.1-or-later.