Not serde, but newer version of rust, no?
Nope, checking GitHub, I can’t see any issues about either of those two things combined with blobs.
Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? I love NixOS, but the hacks they do to injevt determinism are obviously built on implementation details that most upstream projects need to keep opaque to continue improving. I’d much rather see upstream collaborate instead of have nix pees dictate that all current observed behaviour of any piece of software must be set in stone from the first reference in nixpkgs.
Issue was: new type inference caused problems for old version of the time crate. Newer versions worked with 1.80, but many crates weren't updated to the latest.
> Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks?
According to Semver - no. According to people affected - yes.
I often state this, but:
Backwards compatibility ⇒ Semver (read: Backwards compatibility implies SemVer, but not the other way around).
Who's right? Is it fine to speed up compilation but disrupt people using serde on Arch? It depends. According to strict Backwards compatibility guarantee - no. However according to them, you need to backport bugs and exploits.
Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? I love NixOS, but the hacks they do to injevt determinism are obviously built on implementation details that most upstream projects need to keep opaque to continue improving. I’d much rather see upstream collaborate instead of have nix pees dictate that all current observed behaviour of any piece of software must be set in stone from the first reference in nixpkgs.