Re: [PATCH] maint: ship .xz, not .lzma

[Charles Wilson]

On 9/14/2010 11:02 AM, Bob Friesenhahn wrote:
> On Tue, 14 Sep 2010, Gary V. Vaughan wrote:
>>
>> No objections.
>>
>> I'm curious to know what the history of lzma and xz is that makes this
>> desirable though.
> 
> I am curious to know if XZ Utils has now achieved a proper stable
> release or if it will be perpetually in a prototype like state.

Well, the 4.999.9beta is supposedly the "final" beta.  However, it was
released 2009-08-27 (e.g. a year ago) -- so, in order to keep that
promise (!) the webpage now says:

> A snapshot from the git repository is available too, and is generally
> recommended over 4.999.9beta.
>
> xz-4.999.9beta-180-ge23e.tar.gz (1114 KiB)

How that differs from a new RC/beta I don't know, but there you go.
Anyway, if you check the git logs, you'll see that most of the recent
changes have been stabilization and documentation, so I think it is
asymptotically converging on an actual release. Of course you know the
problem with asymptotes...

> Its
> code is quite large and quite obtuse.

Meh.  Most of that is for the alternate compression schemes (e.g. there
are schemes tuned specifically for compressing mips binary code, and x86
binary code, etc).  The core LZMA compression and XZ file format
handling is maybe only 1.5x-2x bzip2.

Take a look at the xz-embedded repo; it includes only the XZ and core
LZMA stuff:
git clone http://git.tukaani.org/xz-embedded.git

> Also, I remain curious to know why 'lzip' has never been considered as a
> suitable replacement.  Lzip accomplishes the same thing with 10 times
> less code, and better fits the traditions previously established by gzip
> and bzip2. 

I'm not sure that last clause (...better fits...) is true. Surely, the
LZMA SDK code and utilities were...different.  But the LZMA Utils and
its successor XZ Utils were *specifically* written to follow the
gzip/bzip2 traditions.

When I added xz support to cygwin's setup.exe via liblzma, the glue code
to do so was VERY similar to the corresponding .gz and .bz2 glue code...
Ditto when similar glue was added to BSD's libarchive.

> Its only limitation is that it requires a C++ compiler.  The
> claim is made that it is not portable because it does not come with a
> megabyte-sized configure script, but it does not need such a huge
> configure script because it only uses portable ANSI interfaces, similar
> to the way gzip only requires ANSI C.  This sort of decision-making
> results in people feeling that GNU software is excessively complex
> bloatware.  Personal politics and status has become more important than
> proper technical analysis.

Err...I don't think I want to get into a religious war. (I will say
this, tho: requiring a 1MB C++ runtime library like libstdc++.so at
*runtime* is not _my_ usual approach when trying to create "non-bloated"
software, and hardly makes up for the "savings" of not having a 1MB
configure script at *build* time.  Sure, on "real" unix you'll already
have that runtime lib installed, but lzma/xz was pitched on unix as
usable on embedded systems and in-kernel too...the same can't be said
for lzip)

The fact is, whether we @ libtool like it or not, .lzma compression had
been adopted by most other GNU projects as "the next great compression
scheme" (whether it really WAS or not, is debatable as all such
assertions are).  When the two primary forces behind lzma-on-unix (Igor
Pavlov and Lasse Collin) got together to formulate the xz extension, the
early .lzma adopters -- e.g. many GNU projects -- followed along.

As one of those GNU projects, automake added support for dist-lzma --
and later dist-xz, not dist-lzip.

That's where we are.

If you want to start an xz-vs-lzip fight, propose the appropriate
support for dist-lzip on automake-patches and fight it there. :-)

--
Chuck