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.

[Pandapip1]

Tracking @Scrumplex's exposing of auto-patchelf: https://nixpk.gs/pr-tracker.html?pr=340162

[nix-owners]

The PR's base branch is set to staging-next, but 159 commits from the master branch are included. Make sure you know the right base branch for your changes, then:

• If the changes should go to the master branch, change the base branch to master
• If the changes should go to the staging-next branch, rebase your PR onto the merge base with the staging-next branch:

  # git rebase --onto $(git merge-base upstream/staging-next HEAD) $(git merge-base upstream/master HEAD)
  git rebase --onto 504e3ecdd9553f0cd5af3305bb7d30d766fbada1 b718c275a9860ac3da020a181c3fc3e9b87d530c
  git push --force-with-lease

[Pandapip1]

Sorry all; realized my mistake right as I hit enter on the force push.