On Thu, May 30, 2019 at 8:40 AM Daniel Mach <dm...@redhat.com> wrote: > > Dne 30. 05. 19 v 0:05 Neal Gompa napsal(a): > > > > I'm pretty sure this would break DeltaRPMs, since none of the drpm > > software has been updated to handle zstd compression. Neither drpm nor > > deltarpm handle it today. > > > Thanks for heads-up. We'll look into it and provide a fix soon.
I think the net resources consumed by all parties needs to be considered. Whether xz:2 or zstd:19, multiplied by thousands of users, that's energy and heat. I have no idea how deltarpm works, but if working on bit level difference on uncompressed data, I don't see why local rebuild needs to use the same compression level as the Fedora build system. If it's working on compressed data, well I'm not sure how that works, in particular if pixz is used which gives non-reproducible results. Another idea for the training dictionary: the training could be done per RPM at create time based on the files for that RPM, and stuff the dictionary in the RPM. No versioning needed. The speed and compression improvements are significant enough it's plausible whatever hit there is for training is overcome by the gain, even at lower compression levels. But it probably needs testing to know. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
