This seems about right.

John Ericson: I understand your thoughts and constraints. I'm not an expert for the packaging for nix packaging tho. By assuring me that you will be available for fixing broken things, I'm okay with updating nix before the first freeze period (2025-04-09). I trust you with your judgement. Also, I will try nix 2.27 as soon as packaging is ready-enough in nixpkgs.
I'm even more happy when you (as in the team) improves the packaging (in the ways emily, ElvishJerricco and others already mentioned), but not change it in major ways after the actual freeze period (2025-04-23). After branch-off, you can of course test changes in packaging and if no breakages occur, also backport them.
Thanks for the open communication style.

I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available.

One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false.

Should the ca metadata be missing in this scenario? Is there a way to put it there?

In reply to @p14:matrix.org

I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available.

One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false.

Should the ca metadata be missing in this scenario? Is there a way to put it there?

Why do I see this difference between the builders of the same unresolved and resolved content-addressed derivation? 🤔

diff /nix/store/q2nzjyqf4w19w3mgbkn34k2as5hrvwh1-builder.sh /nix/store/ckzrg0f0bdyx8rf703nc61r3hz5yys9q-builder.sh
22c22
<     printf '%s ' "${propagatedUserEnvPkgs[@]}" > $out/nix-support/propagated-user-env-packages
---
>     printf '%s ' $propagatedUserEnvPkgs > $out/nix-support/propagated-user-env-packages

In reply to @roberthensing:matrix.org
The --load-db format has come up before. It is entirely forward-incompatible, so we may need to introduce any additions as a new format