| 18 Dec 2025 |
 emily | (you can see the thousands of lines deleted from the compiler derivations in those and the vastly reduced conditional complexity of the derivations, but can't see the burden over time of when stuff breaks) | 13:46:35 |
 Artturin | In reply to @bake.monorail:matrix.org
I'm rather sad that end-of-life'd compilers are dropped from nixpkgs. old compilers are sometimes very useful. is it such a large burden to keep them alive? Luckily it's easy to use a old nixpkgs revision | 13:46:34 |
 bake.monorail | yeah that's a great thing about nix but also not ideal. | 13:47:50 |
| emily | (previously https://github.com/NixOS/nixpkgs/pull/357657, https://github.com/NixOS/nixpkgs/pull/341714) | 13:48:00 |
| bake.monorail | thanks, I will take a look, that's what I was looking for | 13:49:00 |
| emily | in some ways it is ideal: you get a less patched compiler that is closer to the old version you actually want, with versions of its dependencies closer to what it actually expected at the time | 13:52:37 |
| emily | retro X tends to go a lot better with retro Y | 13:52:44 |
| emily | (which is why another side effect of packaging old versions is that you end up with the exponential cost of carrying old versions of entire dependency trees all the way) | 13:53:06 |
| bake.monorail | yeah but importing nixpkgs multiple times is Sad™ | 13:53:37 |
