support for lzip (was: GNU Automake 1.11 released)

[Ralf Wildenhues]

[ adding the automake list; as this is a topic of general interest ]

Hello Antonio, and sorry for the delay,

* Antonio Diaz Diaz wrote on Tue, May 19, 2009 at 06:26:53PM CEST:
> Congratulations on the new release.

Thank you!

> Ralf Wildenhues wrote:
>>
>>   - "make dist" can now create xz-compressed tarballs,
>>     as well as (deprecated?) lzma-compressed tarballs.
>
> 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.

In general, adding support for a new compression format Foo to Automake
incurs several costs, at least with the current way we do things:

- it adds a 'dist-Foo' rule to the toplevel Makefile.in of each package,
- it adds a 'dist-Foo' option to the automake command, which controls
  whether the 'dist' rule also creates tarballs compressed with Foo.
- it tends to promote proliferation of compression formats.  Results of
  this are both increased load on file servers (when several formats are
  offered) and caches/mirrors, and increased pressure on end users (and
  maybe developers, too) to install several decompression tools.

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).
In practice, for me that would mean that, in addition to gzip, I'd offer
one other compression.  zip would fit good for portability; so far I've
gone with bzip2 for Automake, but that should probably be revisited in
the light of recent improvements.

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.

So, where does this leave us for lzip support?  I'm not quite sure
myself.  From a totally non-objective internet search, I see that it
does not have a very large user base; but a comparison with lzma/xz user
base is not conclusive.  From feature set comparison, I don't quite see
the striking advantage that lzip offers over the choices already
available.  If anything, then I don't like encouraging fragmentation of
the API base.

What do other people think?

Thanks,
Ralf