[tz] [PROPOSED PATCH 2/2] Use lz format for new tarball

David Patte ₯ dpatte at relativedata.com
Tue Sep 6 11:51:41 UTC 2016

I agree as well


On 2016-09-06 03:22, Stephen Colebourne wrote:
> I agree with everything Jon just said. Using an unusual and difficult
> to find compression tool is the wrong engineering trade off for this
> project. Sorry, but it really must be zip, gzip or bzip2.
> Stephen
> On 6 September 2016 at 06:38, Jon Skeet <skeet at pobox.com> wrote:
>> This sentence concerns me - the rest of the message sounded good:
>>> Developers can easily get support for all the formats discussed
>> That's just not true. Or rather, it's not true in a convenient fashion. The
>> "tried and tested" compression formats (gzip, zip, even bzip2) have good API
>> support within a broad range of programming languages. It's much easier to
>> write code to deal with a tar.gz file than it is to: a) ensure that the xz
>> tool is installed; b) create a temporary directory; c) shell out to run the
>> tool and check that it was successful; d) use the files; e) clean up the
>> temporary directory.
>> If the only developer use of the files was "extract them from the command
>> line and look at them" then I'd be fine with a relatively obscure
>> compression format, but as developers tend to want to write tools to use the
>> files - preferably without always having to go through the extraction
>> process first - the benefit of wide interoperability trumps compression
>> sizes, for me at least. And as we're only talking about a relatively small
>> number of machines, a difference in compression size won't affect much
>> network traffic.
>> Jon


More information about the tz mailing list