Comment by Nullabillity | Hacker News Reader

Comment by Nullabillity | Hacker News Reader

Parent Full thread

Nix packages refer to each other using absolute paths. The convention is to put them in /nix/store, but technically this base path (the "nix store") be changed to whatever you want. However, changing it requires all (non-leaf) packages to be rebuilt to refer to the new path. That also means that you won't be able to use the central package cache anymore, and you effectively get The Gentoo Experience.

The default path could be changed too, of course, but putting it under your home directory would mean that you could only share cached packages with other people that share your username. It would also break NixOS, since that uses Nix to manage the entire system.

> It means I can migrate things completely by copying one directory, rather than using an "Installer" in the Windows tradition.

Nix ships with a specific tool for copying packages (including dependency trees) between computers, nix-copy-closure. But this also assumes that the store path is the same.

> However, changing it requires all (non-leaf) packages to be rebuilt to refer to the new path.

Do you know whether Nix has a proposal to fix that big ease-of-relocation issue via path rewriting? Afaik Spack package manager builds with padded paths so those can then be rewritten to practically any install path

I haven't kept up actively with core proposals, so I don't know. But I'd doubt it since there's no way to do this generically.. even if you rewrite all paths referring to /foo to instead refer to /bar, that wouldn't cover hashed strings, and would be difficult to do in a way that would make binary formats happy (even if you pad it, `/foo\0\0\0` and `/foo` aren't universally equivalent).

Yeah seems like a nightmare since so much of the auto-magic that nix does to fix binaries (shebang rewriting and ELF .so patching) does so by injecting absolute paths (to /nix/store). So all of those would need to be reshimmed for your entire system

EDIT: theres also work being done to move to content-addressed nix store, in which case changing these things would invalidate the content hash

In Spack we rewrite strings in binaries, strings in text files (including shebangs), and RPATH/RUNPATH values. It's not hard to find store prefixes in binaries -- they have hashes in them so they're easy to identify. It's hard to lengthen them -- things in text files and in ELF fields can be made longer, but to make strings longer you need to find all references to them, which is impractical. So we build with long paths.

Relocating is really only a matter of relocating prefixes.

I am not sure how it would affect a content-addressed nix store, but I'm also not 100% sure why you want a content-addressed nix store. Addressing by the derivation hash (which is also what Spack does) lets you find valid build substitutes... would you index that separately for a content-addressed store?

Is the goal to allow multiple versions of non-reproducible builds in the same store?

I'm not 100% sure, but I know one benefit of content-addressed derivations is that they are secure by default. i.e. if the hash matches the build is trusted vs the traditional need to have separate "trusted signatures" and signing workflow to whitelist particular builders.

How do you reliably modify length-prefixed strings? Terminated strings? Delimited strings? Partial strings? Checksummed strings?

Reply on news.ycombinator.com