@wamserma That doesn’t look to useful for our case. We probably need something tailored towards Nix’ use-cases for the case of chunking. My CrossOver binary tarball from before came out over 100MiB more than any of the other options and it took a minute to compress with no parallelism.
@Atemu I had no idea how it would perform, hence I asked for a test run. Nix- (or rather nar-)specific chunking has been discussed a few times, e.g. in the Attic-Thread.
btw: mbrola is a TTS package and probably pulled in due to this: okular pulls in mbrola worth > 600 mb · Issue #207204 · NixOS/nixpkgs · GitHub
1 Like
zstd is now backported: [2.3-maintenance] libutil: add ZstdDecompressionSink by edef1c · Pull Request #9221 · NixOS/nix · GitHub thanks to @edef !
8 Likes
I opened Tag 2.3.17 from `2.3-maintenance` branch · Issue #9244 · NixOS/nix · GitHub, so this can ideally trickle into a new version number, so (smart) HTTP caches can detect if zstd support is available.
2 Likes
Nix does not support multiple compression methods per .narinfo file. So we cannot offer store paths using both xz and zstd compression.
So it’s not possible to introduce this narinfo extension as non-breaking change, is it?
I have another issue which may or may not be related:
nix flake update --commit-lock-file
given nixpkgs is ± the only flake input, it takes at least 1 min (MBA M1, macOS ) past the download progress has stopped which seems like a bit forever.
not sure if nix-channel --update is any faster, but irrelevant for me as I’ve gone flakes-only due to #10247