Hi,

The xz format is known not to be fit for long term archiving: https://www.nongnu.org/lzip/xz_inadequate.html

But that doesn't mean it should not be used for releases that meant for long term archiving.

Linux for instance uses xz and gzip but it signs the tarball instead of signing the compressed tarball (https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/).

The advantage are (if we do that):
- We can recompress the archive differently if needed and not break signatures.
- If .xz doesn't work anymore or that the files are corrupted somehow, it's possible to check the integrity of the tarball itself without having to trust xz in the process.
- It's easier to reconstruct tarballs from differently damaged files.

The disadvantages is probably that people are more used to check the signature before decompression.

So at some point we probably need to fix the build system to have a release process where the uncompressed files are signed instead and to handle that in the documentation as well.

Using lzip2 is also possible but it's less common and it look painfully slow in some situations and the files are usually bigger than xz -9e.

Denis.