| 20 Mar 2025 |
 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 (any/all) | 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 (any/all) | 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 (any/all) | 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 |
| Randy Eckenrode | I would like to fix the libiconv bugs on Darwin eventually (and try to submit at least my tests to Apple in a feedback in the hope they may also fix things in the platform), but I have no bandwidth for that right now. | 00:02:37 |
| Randy Eckenrode | Also, strictly speaking, Darwin doesn’t even really have a libc package anymore. The libc implementation comes dynamically from which SDK you’re using. The libc package is a stub with empty lib and include directories to prevent spurious warnings from breaking things. | 00:03:39 |
| 22 Mar 2025 |
|  cldrpr joined the room. | 11:46:20 |
