| 29 Jul 2025 |
 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 |
| emily | well, that's why I was asking if you have any examples in mind of things that would make it hard :) | 17:47:42 |
| ElvishJerricco | if someone wants to proof-of-concept it, that would be cool | 17:47:43 |
| emily | I'd be open to poking at it, but it'd of course be nice to start with the hardest thing first to not waste effort on easier stuff | 17:48:09 |
| ElvishJerricco | I don't think any specific things are difficult. It's just a lot of things and its a burden that remains forever | 17:48:15 |
| emily | I think that probably putting a program in a separate output doesn't incur repeated ongoing maintenance costs in most cases | 17:48:46 |
| emily | same way that make-initrd-ng itself doesn't much | 17:48:53 |
| emily | people do closure size minimization work for other reasons, so it's not like it would be burden solely for initrd | 17:49:18 |
| ElvishJerricco | Well if you want to give it a try, it shouldn't be too hard to swap makeInitrdNG for makeInitrd and start slashing away | 17:50:32 |
| ElvishJerricco | (oof, a stock systemd initrd is 21M. not great, but acceptable) | 17:52:20 |
| emily | yeah I might | 18:04:03 |
| emily | even just looking at the diff of the closure would probably make it obvious where to start | 18:04:16 |
| emily | (I thought makeInitrd screws up the store paths or something though) | 18:05:04 |
