This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Steering committee, please, consider using lzip instead of xz

On Wed, 7 Jun 2017 15:25:26 -0700
Matthias Klose <> wrote:

> On 07.06.2017 13:25, Antonio Diaz Diaz wrote:
> > Dear GCC steering committee,
> > 
> > This has been recently asked in this list[1], but in case you have
> > missed it because of a subject line not explicit enough, I would
> > like to appeal to you directly.
> > 
> > [1]
> > 
> > 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.
> > 
> >
> >
> > 
> > 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  
> I proposed and implemented the change to use xz instead of bzip2
> because of the space savings compared to bzip2.  I'm not commenting
> on the "inadequateness" of xz, but maybe it would better help lzip to
> address some project issues and promoting it as an alternative rather
> than appealing to the GCC steering committee.
>  - lzip is not a GNU project (afaics), same as for xz.

The developer is part of the GNU project and the lzip project lives on
Savannah (nongnu).  The license of lzip is under the terms of the GPL.
While the author of xz is not part of the GNU project, the project
lives on, the license is public domain.

>  - lzip doesn't have a public VCS.

The code, license and the releases are a reflection of the "public".
A VCS can be a matter of personal choice, working preference.

>  - lzip doesn't have a documented API, doesn't build as a library,

Under "Related projects" (

Lzlib[1] - A compression library for the lzip file format, written in


>    and I can't find language bindings for lzip.

Well.. this could be done.  lzip is *less* complex than xz.  See[2]:

>  - lzip isn't (yet) used for software distributions, while xz is (and
> afaics xz is used for GNU projects in addition to gz).

Mainstream distributions provides lzip: Fedora, Debian (and
derivatives), Slackware, ...

Attachment: pgpXbiiXkTo_D.pgp
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]