>>>>> "BC" == Ben Cotton <bcotton@xxxxxxxxxx> writes: BC> * The change requires setting a new compression algorithm in rpm BC> macros. Then a mass rebuild of all packages is required. Technically there is no harm if a mass rebuild is not done; there will simply be no benefit for packages which aren't rebuilt. Certainly the change should be made in advance of the mass rebuild, assuming we're going to do one. BC> * The recommended compression level is 19. The builds will take BC> longer, but the additional compression time is negligible in the BC> total build time and it pays off in better compression ratio than xz BC> lvl2 has. That seems different than other results I've seen. According to the wikipedia page (https://en.wikipedia.org/wiki/Zstandard) and the references therein, Ubuntu found that zstd level 19 was faster but with poorer compression when compared with xz level 2 (which is the same level that we use now). I'm not super familiar with zstd but the data presented also implies that multithreaded compression is available and at no loss to package size (unlike parallel xz). But looking at the RPM source, I don't see that the thread count can be specified for zstdio as it can be with xzio (as in setting %_binary_payload to "w2T16.xzdio"). If I'm understanding this correctly, it would be really nice of threaded zstd compression (and decompression) were possible and supported. Finally, note that as far as I can tell, this will render RHEL7 and older unable to decompress Fedora RPMs. RPM 4.14 seems to be required. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
