Jeff Law wrote:
We've got far more important items to tackle than this. But if you
want me to bring it up formally with the SC I can.
ps. And just to be clear, I actually don't like xz and I'm always
annoyed when I run into something delivered in xz format. But xz
support at the distro level is pretty ubiquitous at this point.
Then please, I beg you to bring this up formally with the SC and do your
best to get it considered. As Alexandre Oliva likes to quote, "you must
be the change you wish to see in the world" (Gandhi).
Gzip was once ubiquituous in distro packages and it was replaced. But
this time distros won't lead the change because they can work around the
main defects of xz. As you can read in section 2.2 of
http://www.nongnu.org/lzip/xz_inadequate.html#fragmented
"Distributing software in xz format can only be guaranteed to be safe if
the distributor controls the decompressor run by the user (or can force
the use of external means of integrity checking)".
Distros control the package manager, which can even verify package
signatures by default. For them xz, or even lzma-alone, is good enough.
The only way for distros to change is that a significant number of
upstream projects change first. This is why upstream projects willing
and able to compare lzip and xz based on their technical merits are
required to lead the way.
The level of knowledge, experience and ethical commitment of GNU
maintainers is above the mean of free software developers, and as a
result xz adoption in GNU projects is lower than outside GNU. As you can
see at [1], only a 10% of GNU projects are currently using xz but not
lzip. A number of GNU projects (including those I maintain) are
distributing tarballs in lzip format only. I always expected that GCC
would not adopt xz precisely because of the high level of knowledge and
experience of its main developers.
[1] http://www.nongnu.org/lzip/lzip_benchmark.html#xz1
Thank you very much,
Antonio.
