| 20 Mar 2025 |
 emily | MinGW kinda barely works half the time anyway but it seems fine to put it in stdenv. I'm pretty sure you need libiconv for bootstrap anyway because of GNU build tools wanting it. | 20:58:04 |
| emily | (fwiw, while this is true and we include Apple's libiconv in stdenv, there are also packages that require the GNU one…) | 20:59:15 |
 Alyssa Ross | I remember @Ericson2314:matrix.org wanted to go the exact opposite direction and explicitly specify dependencies on more things that might not be part of libc on all platforms. | 21:05:59 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | About freebsd: https://github.com/NixOS/nixpkgs/commit/2b6b8e29c7696deaf8aefb7c666325354a9e2399
libiconv on freebsd seems to be cursed | 21:06:13 |
| Alyssa Ross | And I broadly vibe with that approach tbh. Explicit is better than implicit. | 21:06:16 |
| emily | (okay let's settle on this room) | 21:06:19 |
| emily | I agree with that in general, but I think that not providing some sort of common base basically just harms rare platforms in practice | 21:06:41 |
| emily | like, if we could mask parts of libc on every platform so you have to specify libiconv, then maybe? | 21:06:57 |
| emily | but what actually happens is that people write packages for the couple of platforms they have access to and then it breaks on other ones | 21:07:15 |
| Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | (i wasn't quite certain, this is very low in dep tree, but not stdenv on all platforms) | 21:07:33 |
| emily | shrinking stdenv is a noble goal in general, but we have tons of build tooling in there already. I think that bundling libraries for things that are in libc on the vast majority of supported platforms makes sense | 21:07:45 |
| emily | in particular there might be a platform with a super tiny libcore and then they have libfs and libmath and so on | 21:08:07 |
| emily | that would be elegant and in an ideal world we'd specify those explicitly | 21:08:13 |
| emily | but in practice if we wanted to support it in Nixpkgs, we'd bundle all of them into stdenv, and I think that's a perfectly reasonable trade-off, even if it's not the most beautiful possible world. adding libmath everywhere would just piss people off and usually not happen | 21:09:03 |
 John Ericson | that was the hope | 21:16:53 |
| emily | then in that case it might be good, but in the current architecture we have it's better to have libiconv in stdenv than to try and get through 5,000 patches to add libiconv to deps lists because "it's needed on OpenBSD" | 21:18:54 |
| 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 |
| emily | you do need -liconv, and we explicitly don't inject that | 21:20:51 |
| emily | build systems have to get that right, which they mosly do | 21:20:56 |
