nix profile: build and read profiles through the store

[domenkozar]

Motivation

nix profile assumes that paths in the selected store are directly accessible through the host filesystem. It builds profile symlink trees in a temporary directory and reads manifest.json through the profile path.

This breaks for stores whose logical paths are not mounted locally, such as rooted or relocated stores.

Build and read profiles through the selected store instead, while preserving existing behavior for regular local profiles.

Context

Profile outputs are now produced by a builtin:buildenv derivation in the selected store. The profile manifest is passed to the builder inline, so constructing the symlink tree no longer requires direct host-filesystem access to store paths.

The supporting changes:

• read profile manifests through the store object accessor;
• retain the filesystem fallback for dangling or non-store profile symlinks;
• detect legacy nix-env profiles without silently treating them as empty;
• allow builtin derivations to run when max-jobs = 0, since they cannot be offloaded;
• validate the buildenv package encoding instead of consuming malformed input unchecked;
• skip unreadable generations in nix profile history with a warning.

Functional coverage includes rooted-store profile creation and updates, the resulting symlink tree and manifest, max-jobs = 0, dangling and non-store-backed profiles, and profile file conflicts.

[xokdvium]

This breaks for stores whose logical paths are not mounted locally, such as rooted or relocated stores.

Hm, but I somewhat fail to see the usefulness of profiles in that case? Such profiles would be broken outside of a mount namespace that is set up for "chroot" stores.

[domenkozar]

That’s expected. For example, while preparing a system under /mnt, its store physically lives at /mnt/nix/store, but becomes /nix/store when that system is entered or booted:

$ nix profile add --store 'local?root=/mnt' --profile /mnt/root/.local/state/nix/profiles/profile …

[Ericson2314]

I never learned why we stopped using builtins:buildenv, so I am happy to see it's return.