nixos/doc/manual: init chapter on fhs binaries

[SomeoneSerge]

This is a work in progress!

I know I'm not a writer, and I'm probably using language and tone inappropriate to the manual, but I am convinced this chapter has to be written and included in the manual. The purpose is specifically to address concerns of the potential and existing NixOS users that require integration with external distributions, including language-specific package managers.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

CC also @NixOS/cuda-maintainers @Mic92

[flokli]

I think it might make sense to describe that nix-built binaries have something like /nix/store/00000000000000000000000000000000-glibc-2.xx-xx/lib/ld-linux-x86-64.so.2 set as dynamic linker.

[Mic92]

One notable limitation where nix-ld won't work, is however if you have try to use a library in a scripting language like python, where the interpreter comes from nixpkgs and hence NIX_LIBRARY_PATH is not effective: https://github.com/Mic92/nix-ld/tree/main#my-pythonnodejsrubyinterpreter-libraries-do-not-find-the-libraries-configured-by-nix-ld

[samuela]

woohoo!

[fricklerhandwerk]

It's a very important topic, and on the technical level this is very thoroughly covered, but I fear in the current state the addition won't alleviate confusion by far as much as it could (and should).

The main problem I see is that the change is trying to do many things at once, and that it doesn't provide enough context for the complex examples. That's generally a problem with the Nixpkgs manual: authors are often so deep into their subject that they find it hard to pick up readers from where they are. And it is work to do that.

Since now a lot of comments have piled up, instead of burdening you with change requests I propose to split out just the problem statement into a PR against the Nixpkgs manual to open a new section. Then we'll have something that can be iterated on with less hassle and merged quickly.

[fricklerhandwerk]

Starting here it gets a bit confusing and repetitive. The confusing part is that the examples assume system state. It's repetitive because all that changes is that each example works in one case but not the other. I think it's enough to point to the option and say it's required to run FHS programs, as they won't work otherwise.

[tejing1]

I'm considering whether to link here in the error message from #269551 to make it much shorter... and I'm not sure. This is written more as an in-depth education on the infrastructure, and solutions aimed more at developers. The message I'm writing will often be seen by quite inexperienced users, and I don't want to throw too big a wall of text at them.

Thoughts?

[SomeoneSerge]

Just to stay in sync: I read and am grateful for all of the feedback. I'll be rewriting this script, hopefully next week. Been occupied elsewhere so far

[Mic92]

I'm considering whether to link here in the error message from #269551 to make it much shorter... and I'm not sure. This is written more as an in-depth education on the infrastructure, and solutions aimed more at developers. The message I'm writing will often be seen by quite inexperienced users, and I don't want to throw too big a wall of text at them.

Thoughts?

I think its fair to have a smaller document just for stub-ld that maybe also link to this one here.

[Mic92]

Just to stay in sync: I read and am grateful for all of the feedback. I'll be rewriting this script, hopefully next week. Been occupied elsewhere so far

I think if you simplify the example as @fricklerhandwerk said in #264433 (comment) than this is good to go.