Re: Autoconf distributions and xz dependency

[James K. Lowden]

On Fri, 2 Mar 2012 22:16:43 -0500
Mike Frysinger <address@hidden> wrote:

> that's a weak argument.  the command line interface to gzip/bzip2/xz
> are largely the same on purpose.  
> 
> xz -dc foo.tar.xz | tar xf -
> xzcat foo.tar.xz | tar xf -

pax -rzf foo.tar.gz

Normally pax/ftp handles the zippiness.  Many people use a GUI
that automatically unzips gzipped files.  If I'm on some ancient system
whose pax/tar doesn't recognize -z, getting xz onto will be at least a
bother, if not a challenge.  

I applaud the autoconf team for quickly deciding in the face of
complaints to retain gzip.  I want to suggest, though, that satisfying
complaints is too low a bar.  Assuming everyone is or should be
chomping at the bit to use xz is a mistake.  

> this largely sounds like "get off my lawn"

Yes, I can master the xz command line.  What I can't do is make an
argument in favor of complexity, especially complexity gratuitously
exposed to the user.  

Why does such an arcane, uninteresting technology warrant advertizing
via a new utility and suffix?  Why isn't xz a feature of zlib, so that
unzipping applications could automatically use it?  If the xz folks
are determined to supplant gzip, why not fork gzip and add xz to it,
or link zlib to the xz utility, so that one command suffices for both?  

As a project downstream from xz, if we must have yet another
compression format independent of gzip, why not let it live along side
the established one(s) until pretty much anything that links to zlib or
similar also supports xz?  

As I see it, it's not an autoconf or even a GNU goal to promote xz.
Autoconf exists to make writing portable applications easier.  Lots of
us who use it don't have any ax to grind regarding compression
utilities; we try to minimize the time we spend re-writing scripts and
dealing with non-project technologies.  Requiring change, even for the
sake of 10% smaller files, just never gets filed under "easier".  

--jkl