Default to zstd compression in v6 format

[pmatilai]

Suggested by @dralley in #2919:
gzip is ubiquitous but also getting long in the tooth and lacking threading options entirely. The best option in 2024 is probably zstd - its fast both ways, multithreads, used widely already and not to be overlooked: has an active upstream.

v6 will of course preserve the ability to switch the compressor, but defaulting to zstd makes it look a little more something from this millenium.

[ffesti]

Guess we should keep the default for source packages at gzip to maintain maximum compatibility. People will want to take srpm back to older versions and will want to at least install them there. Or is zstd old enough that we can assume older but still relevant rpm version would be built with zstd support?

[pmatilai]

Oh, good question. Binary payload is what I was thinking of, anyhow. Sources tend to be compressed as-is, so there's not much benefit trying to further squeeze them.

So yeah, lets leave src.rpm to gzdio.

[pmatilai]

This another example of a seemingly simple thing that on a closer look has all sorts of open questions...

One way to actually "force" our v6 default would be using a different macro for it, eg %_binary_payload_6 and leave the non-versioned to older.

[ffesti]

I don't like that too much. Splitting the settings to different macros is not something we want to get into. Otherwise we'll have to question whether we need two different setting all over the place.

[pmatilai]

That questioning is exactly what we should do actually.

There are other items where the defaults might differ between v4 and v6, including but probably not limited to %_binary_filedigest_algorithm. So it pays to stop to think about it a bit: this is actually a broader problem, so how to handle this in a general manner?

[dralley]

I'm not sure I understand why the default should remain the same. Don't most if not all relevant distros (like Fedora), in practice, override that value with their own distro-default config anyway? In that case, almost all users that care about building such SRPMs would already need to change the config to do so.

edit: or distros can make that decision for them downstream if they deem it worthwhile

Plus zstd support was added in RPM 4.14.0, so it ought to be the case that every distro newer than EL7 ought to support it. And EL7 is completely EOL from an upstream perspective and only receives ELS support. So I would say this is already a fairly minor problem.

[ffesti]

OK, I pushed the macros expression as an example. For rpmbuild settings this could work in general. For rpm proper not so much. But may be there are not that many use cases for rpm itself.