This is the mail archive of the
mailing list for the GCC project.
Re: Steering committee, please, consider using lzip instead of xz
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Matias Fonzo <selk at dragora dot org>
- Cc: Jeff Law <law at redhat dot com>, Antonio Diaz Diaz <antonio at gnu dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 8 Jun 2017 09:48:03 +0200
- Subject: Re: Steering committee, please, consider using lzip instead of xz
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com> <20170607211016.19aac8af@rafaela>
On Thu, Jun 8, 2017 at 2:10 AM, Matias Fonzo <firstname.lastname@example.org> wrote:
> On Wed, 7 Jun 2017 17:18:49 -0600
> Jeff Law <email@example.com> wrote:
>> On 06/07/2017 02:25 PM, Antonio Diaz Diaz wrote:
>> > Dear GCC steering committee,
>> > This has been recently asked in this list, but in case you have
>> > missed it because of a subject line not explicit enough, I would
>> > like to appeal to you directly.
>> >  http://gcc.gnu.org/ml/gcc/2017-06/msg00009.html
>> > Since 2017-05-24 weekly snapshots use xz compression instead of
>> > bzip2. I suppose this means that release tarballs will also use xz
>> > at some point.
>> > If this is the case, I politely request you to consider using lzip
>> > instead of xz. I have spent a lot of time during the last 9 years
>> > developing lzip and studying the xz format, and based on this
>> > experience I consider that lzip is a better choice than xz, now and
>> > in the long term.
>> > I have been developing software since the early 80s, and I am a GNU
>> > maintainer since 2003. You are all experienced developers. All I
>> > ask is that you read carefully the following references and then
>> > consider lzip and xz based on their technical merits.
>> > http://www.nongnu.org/lzip/xz_inadequate.html
>> > http://www.nongnu.org/lzip/lzip_benchmark.html#xz1
>> > Also note that 'lzip -9' produces a tarball a 1% smaller than xz, in
>> > spite of lzip using half the RAM to compress and requiring half the
>> > RAM to decompress than xz.
>> > -rw-r--r-- 1 58765134 2017-06-07 09:13 gcc-8-20170604.tar.lz
>> > -rw-r--r-- 1 59367680 2017-06-07 09:13 gcc-8-20170604.tar.xz
>> Given the breadth that xz already has in the distribution space, I'd
>> have a hard time supporting moving to lz over xz.
>> 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.
> All the important distributions have the lzip tool, besides GNU tar
> has the support for it. If not, it is easy to add lzip for decompress
> the source. This does not affect the preference of the distribution
> for X format in the package redistribution.
While openSUSE has it, SLES does not. tar support seems to be
via calling the external lzip tool (failing if that is not available).
The decision to use xz was largely due to availability. If we use lzip
and 80% of the users have to fall back to the .gz tarball that would