<div dir="ltr">FYI, lbzip2 is what you probably want, as it *can* decompress a &#39;stock&#39; archive faster. From the man page:<br><br>&quot;The lbzip2 utility employs multiple threads and an input-bound splitter even when decompressing .bz2 files created by standard bzip2.&quot;<br><br>That said, I&#39;m in favor of having a list of valid suffixes that it can search for archives against. Doesn&#39;t seem too outlandish. A simple script could be provided for users who would like to recompress their local archives.<br><div><br></div><div>As I posted earlier the benefits of xz (especally xz -9) for clang, llvm, gcc, and boost (some of the biggest archives in my install) were fairly significant:<span style="font-size:12.8000001907349px"> clang-3.5 (50% reduction) llvm-3.5 (49% reduction) and gcc48 and 49 (both ~50% the tbz2 size; only saved 20% with &quot;</span><span class="" style="font-size:12.8000001907349px">xz</span><span style="font-size:12.8000001907349px">&quot; (no -9)).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><br></div><div> - Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 25, 2015 at 4:31 PM, Ryan Schmidt <span dir="ltr">&lt;<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Jan 25, 2015, at 3:27 PM, René J.V. Bertin wrote:<br>
<br>
&gt; On Sunday January 25 2015 14:29:01 Daniel J. Luke wrote:<br>
&gt;<br>
&gt;&gt; and how much more time does it take to compress/decompress?<br>
&gt;<br>
&gt; Decompression is not noticeably slower or faster, compression is. I&#39;d say that shouldn&#39;t be an issue for the build bots, and every user can decide for him/herself whether it is locally.<br>
&gt;<br>
&gt; I&#39;m not working on patches because the support is already there, and requires a point edit in macports.conf to be activated. I&#39;m not familiar with installer development, otherwise I&#39;d propose a patch presenting the user with the choice between xz (slower but more space-efficient compression) and bzip2.<br>
<br>
</span>I&#39;m in favor of making xz the default (there is no need to ask the user about this), the trick would be handling existing installations, which have bz2 archives, without problems, and figuring out how best to handle the pre-built binary packages situation (either write a script to recompress everything as xz, or find a way to have MacPorts check for both).<br>
<br>
One thing to consider is that we somewhat recently made MacPorts base capable of using pbzip2 if it is installed, a parallel bzip2 implementation which uses more than 1 processor core for compression of bz2 files, and uses more than 1 processor core for decompression of bz2 files created with pbzip2. I worked with the developer of pbzip2 recently to improve its build system and to report an intermittent crashing bug, which got fixed, and this now seems to work stably on my system, where I don&#39;t use the binaries from the packages server. However since our buildbot builders do not have pbzip2 active, the archives created by the buildbot builders are not able to be decompressed more quickly by pbzip2 than by bzip2, so it is of limited value. I had considered bundling a copy of pbzip2 with MacPorts to solve this. There seem to be some parallel xz implementations; we should see if any of them is stable enough, and using a suitably compatible license, to consider being included in MacPorts.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br>
</div></div></blockquote></div><br></div>