[ 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
