| 20 Mar 2025 |
 John Ericson | what I mean by mass rebuild is I guess is more just changing hte foundations | 21:24:30 |
| John Ericson | and then fixing all the packages | 21:24:33 |
| John Ericson | few people want to do that | 21:24:37 |
| John Ericson | we need to get the resources somehow | 21:24:46 |
| John Ericson | there is nothing hard about getting out the autotools assumption | 21:24:53 |
| John Ericson | it is just a lot of annoying work | 21:24:57 |
| John Ericson | CA derivations are supposed to help with these things RIP | 21:25:07 |
| John Ericson | (that was my thought so many year ago) | 21:25:17 |
| John Ericson | they still could, to be clear, but just ugh | 21:25:30 |
 emily | I don't think avoiding rebuilds is really a motivation there. we rebuild the entire package set every couple weeks | 21:25:48 |
| emily | it's the manual toil | 21:25:53 |
| John Ericson | emily: the thing that got me before was making a slight tweak to a stdenv script and then rebuilding everything serially, the dream with CA derivations was you could, assuming most things will have the same result, try to rebuild everything in parallel / out of order, using their previous dependencies | 21:38:12 |
| John Ericson | long bootstrapping chains meant lots of O(n) rebuilds when I'd notice a mistake in the things I did to stdenv in some downstream package | 21:39:02 |
| John Ericson | so yes it's manual toil, but debug cycle matters | 21:39:26 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | this whole mess started when i used my unused dependency scanner on mass-rebuild packages. I truly believe there is some potential there to reduce closure size. But i am now seeing iconv is not the first candidate there | 21:46:27 |
