| 15 Feb 2026 |
 K900 | Oh no it won't | 15:51:37 |
| K900 | Yarn vendors it | 15:51:39 |
 emily | so pinning a version seems unavoidable in the long run | 15:51:40 |
| K900 | We may have to do that long term anyway | 15:51:46 |
 Alyssa Ross | In which case we should not overrideAttrs and should just make a separate expression for yarn's zlib-ng. | 15:52:00 |
| emily | so adding a patch revert that violates the guidelines from the checklist doesn't seem acceptable | 15:52:07 |
| K900 | Or we slap upstream with a fish until they concede that this was a terrible idea | 15:52:08 |
 dish [Fox/It/She] | well its more an issue of having to regenerate all hashes of every dependency for every yarn package, no? unless im misunderstanding this | 15:52:15 |
| K900 | Well we can just have a separate zlib-ng-yarn | 15:52:29 |
| K900 | That's pinned to the exact version of whatever the fuck | 15:52:49 |
| emily | why do we need to do this hash in the FOD btw? | 15:53:12 |
| emily | it seems like the same kind of reproducibility-load-bearing logic that makes us reject new complex FOD dep fetchers... maintaining an old zlib forever doesn't sound fun | 15:54:14 |
| emily | we've had to patch Chromium vendored zlibs for new compilers | 15:54:37 |
| emily | the fetchCargoVendor solution is to split the fetcher FOD and the input-addressed derivation that arranges it into the format Cargo accepts, is that not viable here? | 15:57:02 |
| emily | I guess we still might need the old zlib in that drv | 15:57:19 |
