4 ms·

Not conforming to the FHS is what makes Nix possible. You won't get Nix's reproducibility without it.

mixedCase 6y ago
I'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.
- soraminazuki 6y ago
  Nix requires that each package only writes to a dedicated directory in /nix/store. For example, files for Firefox 33.1 package would go into /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1. By not dumping files from every package in a common directory such as /usr, it requires each package to be explicit with its dependencies. This allows for many nice things explained elsewhere (e.g., https://nixos.org/nix/ https://nixos.org/nix/).
  - cauthon 6y ago
    I still don't understand why that can't be solved by putting everything in /opt/nix/store
    - soraminazuki 6y ago
      You've got to keep it mind that Nix was designed as a system package manager and its primary target is NixOS. As such, I'd imagine that it wasn't all that unreasonable for Nix to assume ownership over /nix when the decision was made back then. Since Nix doesn't organize files according to FHS recommendations, it's never going to be FHS compliant. If so, what benefits would there be for Nix to choose /opt/nix over /nix? After all, /opt is where third-party packages reside and hardly the right choice anyways. The fact that Nix can be used as a third-party package manager outside of NixOS was a nice side-effect of its design choices. If Nix was designed from the start as a third-party package manager, it might have placed itself in /opt/nix. However, Nix was made years before some platforms started to lock down the root directory. It worked perfectly well with /nix before this happened. So instead of asking why Nix is placing itself in /nix instead of following some guidelines for traditional unix distributions, I think we should be asking why platforms are disallowing this. If a platform is going to make this big a breaking change, it'd better have a very good reason to do so. I fail to see the reason beside subjective aesthetics.
acdha 6y ago
Can you explain the reasoning here? I can see it being _easier_ than doing it the right way but have trouble coming up with a scenario where it makes it _impossible_.
- arianvanp 6y ago
  Packages can not 'accidentally' depend on other packages as the only way to depend on a package is by referring to their full path which your learn by evaluating that package. If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later In nix you can't do this as you don't know nginx's path without defining a dependency on it; so you don't gain undeclared dependencies on accident. By forcing a different path you find these things at build time not at run time.
  - arianvanp 6y ago
    But yeh rooting everything under /usr/nix or /opt/nix would've probably been a better choice. What annoys me more is that a popular nix Fork GNU Guix _did_ change the path; but they made the same mistake again (it's rooted under /gnu) whilst they already has the hindsight that a non-standard directory might be problematic
  - acdha 6y ago
    Nothing about that says that the path has to be /nix — it would work just as well with the standard layout under /opt/nix. It also seems like it doesn't really help with the stated problem since a developer who would hard-code /usr/bin/nginx but not list it as a dependency would almost certainly just use whatever `which nginx` returns. The thing which would solve that is depending on a precise version or hash, and if you're doing that, the path prefix doesn't really matter.
jeremyjh 6y ago
/opt/nix is FHS compliant and would work fine.

I'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.

soraminazuki 6y ago
Nix requires that each package only writes to a dedicated directory in /nix/store. For example, files for Firefox 33.1 package would go into /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1. By not dumping files from every package in a common directory such as /usr, it requires each package to be explicit with its dependencies. This allows for many nice things explained elsewhere (e.g., https://nixos.org/nix/ https://nixos.org/nix/).
- cauthon 6y ago
  I still don't understand why that can't be solved by putting everything in /opt/nix/store
  - soraminazuki 6y ago
    You've got to keep it mind that Nix was designed as a system package manager and its primary target is NixOS. As such, I'd imagine that it wasn't all that unreasonable for Nix to assume ownership over /nix when the decision was made back then. Since Nix doesn't organize files according to FHS recommendations, it's never going to be FHS compliant. If so, what benefits would there be for Nix to choose /opt/nix over /nix? After all, /opt is where third-party packages reside and hardly the right choice anyways. The fact that Nix can be used as a third-party package manager outside of NixOS was a nice side-effect of its design choices. If Nix was designed from the start as a third-party package manager, it might have placed itself in /opt/nix. However, Nix was made years before some platforms started to lock down the root directory. It worked perfectly well with /nix before this happened. So instead of asking why Nix is placing itself in /nix instead of following some guidelines for traditional unix distributions, I think we should be asking why platforms are disallowing this. If a platform is going to make this big a breaking change, it'd better have a very good reason to do so. I fail to see the reason beside subjective aesthetics.

acdha 6y ago

Can you explain the reasoning here? I can see it being _easier_ than doing it the right way but have trouble coming up with a scenario where it makes it _impossible_.

arianvanp 6y ago
Packages can not 'accidentally' depend on other packages as the only way to depend on a package is by referring to their full path which your learn by evaluating that package. If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later In nix you can't do this as you don't know nginx's path without defining a dependency on it; so you don't gain undeclared dependencies on accident. By forcing a different path you find these things at build time not at run time.
- arianvanp 6y ago
  But yeh rooting everything under /usr/nix or /opt/nix would've probably been a better choice. What annoys me more is that a popular nix Fork GNU Guix _did_ change the path; but they made the same mistake again (it's rooted under /gnu) whilst they already has the hindsight that a non-standard directory might be problematic
- acdha 6y ago
  Nothing about that says that the path has to be /nix — it would work just as well with the standard layout under /opt/nix. It also seems like it doesn't really help with the stated problem since a developer who would hard-code /usr/bin/nginx but not list it as a dependency would almost certainly just use whatever `which nginx` returns. The thing which would solve that is depending on a precise version or hash, and if you're doing that, the path prefix doesn't really matter.

jeremyjh 6y ago

/opt/nix is FHS compliant and would work fine.