envision: autopatchelf after build

[Pandapip1]

Description of changes

Adds an OpenXR document to establish an expectation (and a little bit of responsibility), and updates envision to align with that new document. This is necessary because otherwise all OpenXR applications would need to run in a fhsenv with a list of commonly-used provider dependencies.

Also makes envision align with said document.

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

---

Add a 👍 reaction to pull requests you find important.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review/3032/4485

[Aleksanaa]

There's autoPatchelfHook, not sure if that (unmaintained) tool would be helpful

[Pandapip1]

I'm aware autopatchelfHook exists, but it doesn't actually expose the autopatchelf binary.

[Artturin]

I'm aware autopatchelfHook exists, but it doesn't actually expose the autopatchelf binary.

Maybe expose it in the passthru of autoPatchelfHook if its maintainers are ok with that.

The old autopatchelf needs to be clearly labelled as old-autopatchelf to make sure no one uses it. (preferably it's not added to nixpkgs)

[Pandapip1]

The old autopatchelf needs to be clearly labelled as old-autopatchelf to make sure no one uses it. (preferably it's not added to nixpkgs)

Out of curiosity, why shouldn't it be used?

[Artturin]

The old autopatchelf needs to be clearly labelled as old-autopatchelf to make sure no one uses it. (preferably it's not added to nixpkgs)

Out of curiosity, why shouldn't it be used?

It's likely lacking all the fixes the in-tree auto-patchelf.sh had before being rewritten in python and the fixes the python version has

[Scrumplex]

Maybe expose it in the passthru of autoPatchelfHook if its maintainers are ok with that.

I have proposed #340162 for this ^^

[ElvishJerricco]

@Pandapip1

I'm aware autopatchelfHook exists, but it doesn't actually expose the autopatchelf binary.

Because it doesn't use it. That binary is obsolete and what we use now is in-tree.

[Pandapip1]

Yeah, @Scrumplex already told me that. I'm reviewing their PR to expose it.