extra: +19553.0 KiB
initrd-linux: -52.8 KiB
nixos-system-monitoring: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-payments: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage001: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage002: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage003: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage004: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage005: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage1: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nixos-system-storage2: 21.05.4388.a284564b7f7 → 21.05.4448.4a8751d694b
nspr: 4.30 → 4.32
nss: 3.64 → 3.68.1, +29.6 KiB
strace: 5.14 → 5.15, +89.5 KiB
udev: +37.7 KiB
udhcp: ∅ → εI think the new dependency on udhcp (technically the udhcp-script from the initrd) is a false positive inclusion in the closure. It appears to be a quirk of how the initrd image is compressed (specifically, the new initrd includes a portion of script verbatim in the compressed archive, and nix see store identifiers in them, which it treats as dependencies). I ran diffoscope against the two initrd's, and as far as I noticed while scanning, the only difference is the embedded store paths and nothing else[1].
[1] This isn't terribly surprising, the initrd depends on the cloud-utils guest output. cloud-utils depends on qemu, but that doesn't impact the contents of the guest output, so only the store path changes (since that depends on all the inputs).