Daniel Alley

It kind of seems like a `python-zstd` issue? https://github.com/sergey-dryabzhinsky/python-zstd/issues/53#issuecomment-703916532 >Decompression fails where no content size is included in the frame (e.g. streaming) > ... > (reply) > Yes, this module...

Sidenote, I'll plug that it would be great to get `zstd` support into the Python standard library.

Supposedly this works ``` with zstd.ZstdDecompressor().stream_reader(io.BytesIO(compressed)) as r: decompressed = r.read() assert decompressed == data ``` https://github.com/indygreg/python-zstandard/issues/150

Suggestion: switch to zlib-ng instead. The speedup is significant and probably comparable or better than multi-threading the current zlib. https://github.com/zlib-ng/zlib-ng/discussions/871 It is available in Fedora, though not EL. Also, Xz...

I'm not actually suggesting it be done immediately, I'm just saying (on a 6 year old RFE) that now that we're in the future this would be a better approach...

Would it come with the expectation that I would be responsible for seeing it through? Because I definitely don't have the C background necessary to do that for a core...

@kontura IMO the switch to zstd as default means we can drop this.

zstd also has an rsyncable mode.

@Conan-Kudo Thanks for the heads up. It would be great if this clarification was applied to the repos and documentation, because there is no external indications that one of them...

I think the confusing part is that the Fedora repositories themselves don't work this way, they use this crazy approach with packing the metadata into the `appstream-data` RPM