| 20 Mar 2025 |
 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 |
| John Ericson | it would be nice to build the more minimal thing and then bundle it | 21:53:34 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | oh i am seeing there is no consensus, i am happy you were willing to entertain my dumb unqualified ideas. I am excited to see what comes of your attempt, if you do try - but i think this is beyond me (for now). | 21:55:33 |
| emily | glibc's iconv APIs are not the same as GNU libiconv FYI | 22:20:54 |
| emily | I don't think modifying libc build systems would be a good idea. I think generating stubs of API subsets would be more reasonable. | 22:21:28 |
| emily | (since if we are doing "rearchitect all of Nixpkgs" type solutions then we need dynamic library stubs to get any real advantage out of ca-derivations anyway.) | 22:21:37 |
 Randy Eckenrode | In theory, this is a bug in Apple’s libiconv. According to comments in the source, the rewrite is intended to be compatible with GNU stuff. It’s just not in places. Good luck with submitting feedbacks though …. | 23:59:41 |
| 21 Mar 2025 |
| Randy Eckenrode | Git being a notable example. It depends on a special UTF-8 codec on Darwin to handle Unicode normalization. | 00:01:39 |
