| 29 Jul 2025 |
 ElvishJerricco | I mean I can think of how to do it with no new features too | 17:37:08 |
 emily | would you like it if we just… made the closures of things small enough that we can use it for everything? | 17:37:15 |
| emily | without the current hacks | 17:37:23 |
| ElvishJerricco | i.e. make a derivation that creates symlinks to everything listed in a ${closureInfo}/store-paths | 17:37:38 |
| ElvishJerricco | that's really not going to happen | 17:37:47 |
| emily | I genuinely think it could! | 17:38:04 |
| emily | what do you think the blockers would be? (we could discuss in the systemd room) | 17:38:12 |
| ElvishJerricco | even if we split binaries from everything else in every relevant derivation (which is a lot of derivations), there's still way more binaries than necessary in a lot of those derivations | 17:38:33 |
| emily | it doesn't have to be a monolithic bin, we do split out individual binaries into their own outputs when necessary | 17:39:02 |
| ElvishJerricco | even still, I don't like the idea of having to carefully watch over every derivation in the initrd dependency tree to make sure that none of them ever leaks something big in for the rest of time. | 17:40:03 |
| emily | we can have a CI test that asserts on the initrd size | 17:40:32 |
| ElvishJerricco | and having code all over nixpkgs to fix a lot of derivations just for the sake of initrd seems like a bad smell | 17:40:36 |
| emily | well, a Hydra one rather | 17:40:36 |
| emily | which is good to have in general | 17:40:41 |
| emily | (we have it for the ISO) | 17:40:43 |
| emily | I don't think so. split outputs and feature flags are there to reduce closure size where it matters. we don't like to do it without strong reason, but packages going into initrd is a strong reason | 17:41:12 |
| emily | and if we can accomplish it without breaking the normal Nix closure mechanism that's better and means that other usecases can also benefit from the reduced closure | 17:41:48 |
