Using xz by default for compression

[Ryan Schmidt]

On Jan 26, 2015, at 4:06 AM, Ryan Schmidt wrote:
> 
> On Jan 26, 2015, at 3:17 AM, Rainer Müller wrote:
> 
>> 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.

Upon further investigation, hfscompression uses zlib, and has further optimizations for small files:

http://wiki.sleuthkit.org/index.php?title=HFS#HFS.2B_File_Compression

Re-reading the ticket above, it sounds like it's talking about the files that get installed when a port is activated. Yes, hfscompression would benefit that situation and we should do it, if all the concerns in the ticket have been addressed.

Archives, however, will not benefit from being zlib-compressed; using hfscompression on our current bz2 archives would not save any space, and using hfscompression on uncompressed tar archives would take more space than our current bz2 archives.

So yes, we should pursue hfscompression, but it is orthogonal to the issue discussed in this email thread.