[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: support for lzip

From: Antonio Diaz Diaz
Subject: Re: support for lzip
Date: Fri, 12 Jun 2009 17:24:54 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905

Ralf Wildenhues wrote:
* Antonio Diaz Diaz wrote on Tue, May 19, 2009 at 06:26:53PM CEST:
Do you plan to support the creation of lzip-compressed tarballs?

Well, to be honest, I regard the addition of lzma support as a mistake
in hindsight.  We should have waited and added xz support only, with a
stable xz release.  It was also a mistake that I did not deprecate lzma
support more prominently in the 1.11 release; will fix that for 1.11.1.

I agree that adding lzma_alone support was not a good idea. (Among other things, long term archiving of compressed data without integrity checking can easily produce undetected data corruption).

What I ask myself is, given the excessive complexity of the xz-utils code and format, will we ever see a stable xz release? And even if a "stable" xz is released, how stable can it be given that xz uses the still in development LZMA2[1] algorithm?

Lzip provides "security through simplicity". Given the simplicity of the lzip code and format, I think it is a much better choice for long term archiving than xz. Aren't, for example, tarballs of GNU packages supposed to be permanently archived for, among other things, copyright related purposes?

Here's my own personal preference: I'd offer packages in two or at most
three formats only: one that is widely usable (gzip fits this well), and
one that offers a mixture of best compression and lowest extraction work
(so that, with many downloads, bandwith and CPU cycles are minimized).

I totally agree. Currently I am distributing tarballs compressed only with gzip and lzip.

Of course, there is not much reason the priorities for Automake users
should equal my personal ones; rather, Automake should be usable for a
broad range of developers, and it should provide a reasonable range of

Supporting a fast and widely used compresor (gzip) plus one with better compression and low extraction work (lzip) provides IMO a reasonable range of functionality.

From feature set comparison, I don't quite see the striking
advantage that lzip offers over the choices already available.

Lzip offers the advantage of simplicity. This is why lzip reached stable status in much less time than lzma-utils or xz-utils. This is also why there are already two independent implementations[2] supporting the lzip format whereas only xz-utils supports the xz format.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]