hey, is there anything interested parties could look at contributing on this, or a rough outline of the intent? I'm very keen to see it land!

First I have to generate a JSON manifest from hjem.files, validate it with CUE, and use system.extraSystemBuilderCmds to write it to a stable location.
Then I'll write a script that uses the "linker" (probably going to change the name to "file handler" in line with smfh) to read the current and previous manifest and lets it create and remove the files as needed.
Since we need to read the previous manifest, that requires running this during activation via an activation script ($systemConfig for currently activating generation, and /run/current-system for the prior one).
And of course corresponding VM tests.

Longterm I'm not a huge fan of the activation script approach, as I'd like to provide a way to bail out in case things go sideways.
In general making activation scripts "heavier" also affects every single boot, so I also want to make sure it's performant and not likely to fail mysteriously.

I was hoping that we'd be able to avoid activation scripts long-term as well. Is there a possibility that we discover the previous generation on our own accord instead of relying on $systemConfig etc. ? There should be a reasonable method of reaching the same "calculation" inside a systemd service, or whatever solution we wish to pick.

I was hoping that we'd be able to avoid activation scripts long-term as well. Is there a possibility that we discover the previous generation on our own accord instead of relying on $systemConfig etc. ? There should be a reasonable method of reaching the same "calculation" inside a systemd service, or whatever solution we wish to pick.

Technically, we could handle this with systemd OneShot services. The main challenge would be to make it run automatically after every rebuild, and on boot, but I'd also be more for that approach.

Could we link the manifest to a location which the service can access? Would that be a problem?

This approach would also make handling different systems more difficult (as we'd either need to handle this with launchd or activation scripts on darwin)

Could we link the manifest to a location which the service can access?

I'm already using extraSystemBuilderCmds (unpushed changes) to create something like <generation>/hjem/manifest.json which is a stable location relative to the current generation. In the case of switching the location of the previous generation is /run/current-system which is accessible anywhere, that's not an issue. However, the new generation is located at $systemConfig which is an envvar populated by the cursed perl activation script and I don't know where else to get that information. Do you have a suggestion on how to do that?

Alternatively, we would have to start maintaining our (hjem's) own state in some state dir but I'd consider that design as a last resort.

handling in #34