Re: support for lzip

[Antonio Diaz Diaz]

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?
> > http://lists.gnu.org/archive/html/automake/2008-11/msg00076.html
>
> 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?
[1] http://en.wikipedia.org/wiki/Lempel-Ziv-Markov_chain_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
> functionality.

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.
[2] http://riemann.fmi.uni-sofia.bg/lzma/lzma.man


Regards,
Antonio.