Using xz by default for compression

[Ryan Schmidt]

On Jan 26, 2015, at 3:17 AM, Rainer Müller wrote:

> On 2015-01-25 22:27, René J.V. Bertin wrote:
>> I'm not working on patches because the support is already there, and
>> requires a point edit in macports.conf to be activated. I'm not
>> familiar with installer development, otherwise I'd propose a patch
>> presenting the user with the choice between xz (slower but more
>> space-efficient compression) and bzip2.
> 
> The transition from one compression format to another would most
> definitely require patches to handle local .tar.bz2 archives and also
> download new .tar.xz archives.
> 
> There is no /usr/bin/xz on my OS X 10.10 Yosemite. If we want to switch,
> the xz utility would have to be shipped with MacPorts base. Is the
> higher compression worth the effort to maintain another dependency in
> our repository?

Yes it is better to use xz than bz2. Even if /usr/bin/xz existed in OS X, we would still want to bundle a parallel xz implementation with MacPorts for faster speed.


> Also, as this is all about saving disk space, I would like to point to a
> patch using the builtin HFS compression when available. This patch was
> submitted by Michael Feiri (mfeiri@) in multiple revisions already. It
> does not introduce new dependencies and most probably saves way more
> disk space than compressing the archives with another algorithm.
> 
> http://trac.macports.org/ticket/36560

I forgot about that as well. But what compression algorithm does hfscompression use, and why are you so sure it will save "way more disk space than" xz? Have we tested that? Compressed disk images, for example, originally used zlib compression, and as of Tiger support bzip2 compression, but xz would be smaller than both of those. Granted hfscompression was introduced after that, in Snow Leopard, so it may well use a more advanced algorithm, I don't know.