Reading through the changelog, this might require a change in some module:

nss-mymachines lost support for resolution of users and groups, and
          now only does resolution of hostnames. This functionality is now
          provided by nss-systemd. Thus, the 'mymachines' entry should be
          removed from the 'passwd:' and 'group:' lines in /etc/nsswitch.conf
          (and 'systemd' added if it is not already there).

@ajs124 These are the corresponding lines: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/systemd.nix#L902,L916

We also should review #91960 before merging this, rebase this PR on top and update the options in there.

I rebased this on latest staging, and updated the documentation regarding on how to do updates as suggested by @andersk in #94681 (comment).

Still haven't yet looked into how to fix the cyclic dependency between the different outputs - help appreciated.

I did look a bit at this with @arianvp. libsystemd-shared.so contains some code used by many of the systemd binaries. It itself uses libsystemd.so (which is in the lib output). I think this is fine.

What's not fine (and seems to have changed in 9c5bb2033db0c0927593b929ff760b69295a9f70) is that libsystemd.so now contains a get_path helper function containing references to ROOTPREFIX (which points back to ${systemd.out} in our case).

I'm not yet sure on whether these are used (and simply not garbage collected), similar to the situation on aarch64.

Apparently these paths are in the library are now also exposed by sd_path_lookup*, which seems public libsystemd API :-/ (thanks @jtojnar)

I'm not really if it's wise to put all this logic into a generic library other applications link against, if it still contains hardcoded paths - IMHO, these applications should either ask the systemd .pc files during build-time, or if this can change at runtime, the libsystemd API should ask the running systemd for the paths currently active on the system, by asking pid 1 via IPC.

I'll take a look where this method is used inside of systemd itself, and whether we can/want to point these paths to something else (either by changing meson flags, or by patching the code). It seems some of the code added in above commit doesn't properly honor the path structure anyways, but uses some hardcoded strings in first place - maybe we should have a discussion with upstream about how to structure these paths.

If this all doesn't work out, we might have to give up the multi-output nature of systemd (and ship everything in a bigger single output).

Yeah, I planned to talk more with upstream and see if we can get some of the path handling there unified. For now it's probably fine to drop the lib output.

This PR probably just needs some more thorough testing in everyday usage, and someone toying with the watchdog options.

Edit: I opened systemd/systemd#16747 for now and will have some more discussion in the following days, but none of this blocks that PR.

What's the status of this PR?

I ran this on my laptop for a week or two and didn't spot any issues. I haven't figured yet out why the watchdog part of the test is failing.

I propose commenting this out and then merging this in.

I'd really like to see this in 20.09, and we'd still need to have it go through a staging round.

Right. I am about to start a new staging-next iteration which most likely would be the last one.

Alright, let me fix the test and then merge this in.

There will likely be some follow-up PRs to expose new systemd options in the module system, but that's no world rebuild, so should be fine.

This broke fwupd: #96663.

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

https://discourse.nixos.org/t/marketing-team-can-we-present-nix-nixos-better/6249/106