Karl Berry <[email protected]> writes:
> Regarding https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62069.
>
> Given Kamila's point about reproducibility, and the xz version
> dependence of the feature, I don't think we should change automake's
> default of unthreaded.
I can't speak to Kamila's point about reputability or stability since it
isn't my area of expertise, but I think that just invoking the command
with none (or minimal) options is a reasonable choice. Package
maintainers can make their own decisions on whether they want new
compression features or maximize portability, for example.
> Thus I think the only change called for here is to update the doc to
> mention that -T0 (or another value) can presumably be added to XZ_OPT if
> a maintainer wishes to make thread-dependent, and xz-version-dependent,
> tarballs.
Yes, it works fine. In coreutils we have the following in cfg.mk:
# Comparing tarball sizes compressed using different xz presets, we see that
# an -8e-compressed tarball is only 9KiB larger than the -9e-compressed one.
# Using -8e is preferred, since that lets the decompression process use half
# the memory (32MiB rather than 64MiB).
# $ for i in {7,8,9}{e,}; do \
# (n=$(xz -$i < coreutils-8.15*.tar|wc -c);echo $n $i) & done |sort -nr
# 5129388 7
# 5036524 7e
# 5017476 8
# 5010604 9
# 4923016 8e
# 4914152 9e
export XZ_OPT = -8e
Many of the packages Jim Meyering maintains have similar lines (I'm sort
of surprised he didn't add it to 'make dist' for Automake's tarballs).
FWIW, we haven't run into any complaints about the xz formatted tarballs
in coreutils because of this. They seemingly work fine everywhere. There
was a minor exception where GNU Guix wanted gzip'ed tarballs for
bootstrapping, but I think they haven't needed that for a while now.
Collin
