| 20 Mar 2025 |
 emily | * build systems have to get that right, which they mostly do | 21:20:57 |
 John Ericson | as we were discussing before with compiler-rt | 21:20:59 |
| John Ericson | libc is just a bad layer of abstraction | 21:21:07 |
| John Ericson | and it's very viral | 21:21:10 |
| John Ericson | it is frustrating | 21:21:27 |
| emily | I think us establishing some baseline API that gets offered for C programs even if it has to be composed out of multiple packages is not really the worst thing in the world | 21:22:15 |
| emily | even if we had everything perfectly factored out into totally orthogonal pieces on every platform, I think people would be unhappy about writing 50 lines of boilerplate for libraries that are "always there" in every single package | 21:22:46 |
| emily | stuff like factoring out autotools assumptions is much higher-value IMO | 21:22:55 |
| John Ericson | there should be some baseline API | 21:23:25 |
| John Ericson | but "repeating the boilerplate is annoying" is rather a slipperly slope | 21:23:37 |
| John Ericson | because adding more stuff always cuts more downstream dependenices | 21:23:49 |
| John Ericson | no disagreement | 21:24:05 |
| 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 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | i did find our git has a dependency on cpio that has been unnecessary for the past 9 years, for example - git release notes confirm that. However, lesson learned, i will leave iconv alone for now | 21:47:21 |
| John Ericson | Grimmauld (any/all): of course per the above you can see there isn't concensus, but I would still like to know whether it is possible to build glibc without libiconv | 21:53:10 |
| John Ericson | even if stdenv contained libiconv | 21:53:23 |
