| 20 Mar 2025 |
 emily | since people will never reliably get it right if it only breaks on an obscure platform, and having (perceived-as-)noise in a package only required for one platform annoys people | 21:19:12 |
 John Ericson | what is the darwin situation? | 21:19:16 |
| emily | we add Apple's libiconv to stdenv | 21:19:24 |
| emily | we didn't use to, but we do as of the recent rewrite | 21:19:29 |
| John Ericson | :/ | 21:19:38 |
| emily | there was a lot of ++ lib.optionals stdenv.isDarwin [ libiconv ] before, which isn't even correct | 21:19:41 |
| John Ericson | we have "avoid mass rebuild" perverse incentive | 21:20:01 |
| John Ericson | it is easy to just bloat things more and more | 21:20:06 |
| emily | nothing to do with mass rebuilds | 21:20:13 |
| emily | we rewrote the entire stdenv | 21:20:20 |
| emily | FWIW, Apple's libiconv is effectively part of the system library on macOS insofar as they only compilation environments they ship have direct access to it | 21:20:24 |
| emily | there's never a case where you could be compiling software for macOS in any normal way and not have libiconv right there | 21:20:37 |
