| 18 Dec 2025 |
 matthewcroughan | the maintenance status of retro68 makes it pretty valid for inclusion in nixpkgs instead of being its own flake though | 13:33:11 |
| matthewcroughan | whereas an out-of-date unmaintained thing is less relevant for nixpkgs inclusion | 13:33:30 |
| matthewcroughan | still shows how you can provide all that infra just fine outside of nixpkgs though | 13:33:46 |
| matthewcroughan | Like, overlays, overrideAttrs, override, all provide you with ways of achieving what you want to do, you can't keep everything forever in the tree | 13:35:37 |
 bake.monorail | I feel you're being a bit unnecessarily adversarial. this said, having an overlay is quite different story, since it does not enable you to reuse "private" logic from nixpkgs.
for instance, in the GCC package it's not possible to override the versions without forking (there's a "private" variable determining the versions). | 13:35:42 |
| bake.monorail | * I feel you're being a bit unnecessarily adversarial. this said, having an overlay is a quite different story, since it does not enable you to reuse "private" logic from nixpkgs.
for instance, in the GCC package it's not possible to override the versions without forking (there's a "private" variable determining the versions). | 13:36:13 |
| matthewcroughan | Not at all trying to be adversarial, just stating that if you want something like you're asking for, you should maintain it in your own tree, and this is what other people do too | 13:36:18 |
| matthewcroughan | And that there's nothing too bad about providing toolchains in overlays | 13:36:41 |
| matthewcroughan | like providing toolchains as overlays in nix works well | 13:37:04 |
