4 ms·

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

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.

eviks 3y ago
> 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
- Nullabillity 3y ago
  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).
  - JamesSwift 3y ago
    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
    - tgamblin 3y ago
      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?
      - JamesSwift 3y ago
        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.
      - Nullabillity 3y ago
        How do you reliably modify length-prefixed strings? Terminated strings? Delimited strings? Partial strings? Checksummed strings?

eviks 3y ago

> 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

Nullabillity 3y ago
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).
- JamesSwift 3y ago
  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
  - tgamblin 3y ago
    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?
    - JamesSwift 3y ago
      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.
    - Nullabillity 3y ago
      How do you reliably modify length-prefixed strings? Terminated strings? Delimited strings? Partial strings? Checksummed strings?