| 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 |
| ElvishJerricco | It just seems like a major burden to be putting on nixpkgs that will require a notable amount of manual effort perpetually. I'm opposed. | 17:41:58 |
| emily | I think it's also a burden to not be able to put packages in initrd without them breaking surprisingly because their closures got clipped | 17:42:58 |
| emily | do you have examples of things you think would be hard to split up to achieve the same results make-initrd-ng does? | 17:43:19 |
| ElvishJerricco | but that's a much smaller burden because it only affects the packages that we can't automate with make-initrd-ng. The burden the other way is strictly greater because it necessarily includes those same cases and more. | 17:44:07 |
| emily | when stuff doesn't need things that are in their closure to work, that's a non-ideal situation in general, if there's a reason you'd want to use them in size-constrained environments and the burden of splitting isn't too high (and the fact that make-initrd-ng produces something that works with them means that it shouldn't be too hard to split anything that does go in there now, by definition) | 17:44:24 |
| emily | no, I mean, if someone wants to include a full Python application in their initrd and pay the cost it seems fair that it should work | 17:44:49 |
| emily | so there wouldn't be a closure minimization cost paid there | 17:45:00 |
| ElvishJerricco | I think in a perfect world every binary would be its own output path in every single package and this would be trivial. But that's not what we have. | 17:45:45 |
| emily | I might be wrong about the work it'd take to split things up! but my prediction is that using the normal closure mechanisms and just splitting up packages where relevant is not going to look more complex than what we do instead right now | 17:45:50 |
| ElvishJerricco | which leaves me believing this^ | 17:45:53 |
| emily | there aren't that many things in initrd | 17:45:57 |
| emily | and if we have checks for initrd size (which seems good in general to stop it growing accidentally for other reasons) then it seems like the burden would be appropriately distributed to maintainers of core packages with passthru.tests | 17:46:56 |
| ElvishJerricco | I'm just not convinced it's worth the effort, or sustainable | 17:47:15 |
