>>>> "BC" == Ben Cotton
<bcotton(a)redhat.com> 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<