[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: support for lzip
Antonio Diaz Diaz
Re: support for lzip
Fri, 12 Jun 2009 17:24:54 +0200
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 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
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 supporting the lzip
format whereas only xz-utils supports the xz format.