--On Friday, March 25, 2011 11:17 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com&gt; wrote: All tests pass for me on Fedora 11 64-bit (linux 2.6) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Tests succeeded on FreeBSD/amd64 9-CURRENT. By the way, can we consider releasing the tarball with some modern compressor, for example xz or bzip2? I have done some test on FreeBSD, with a simple gunzip/xz -9e cycle, the size reduced from 5240643 to 3439792 (34% smaller). A gunzip/bzip -9 cycle would reduce the file to 4227655 bytes (20% smaller). It seems to be worthy for the 20% (if we use bzip2) or 34% (if we use xz) bandwidth saving I think. Cheers, - -- Xin LI <delphij(a)delphij.net&gt; http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

On Mar 25, 2011, at 1:01 PM, Xin LI wrote: First, the best time to choose a compressor is at the first release of the package. The longer a package been in distribution, the more risk of there is due to breakage of reliance of release conventions. Switching, I think, would be a really bad idea (I'm not sure you were suggesting this, I'd guess you were suggesting adding an additional compressor). But even adding a new compressor (as opposed to switching compressors) can lead to breakage in various download, verify, and/or extract scripts. If I were to select a compressor anew for some new package, I might select bzip2 over gzip. However, I would be concerned that it's marginal compression gains come at significant computing resource consumption during compression and decompression. As I find it easier to obtain donations of bandwith than computing resources, I'm more apt to favor gzip over bzip2 even today for source releases. I also feel that gzip has better proven portability than bzip2 and that bzip2 has better proven portability over xz. I also note that xz is not available in the default install in all modern UNIX systems, nor is it widely integrated in tar(1) compatible extractors. I would, in making such a choice for a new package, or subsequently (as with OpenLDAP packages), avoid having multiple compressors if I could because that effectively doubles backup storage/bandwidth requirements for the tarballs. Lastly, if one could actually reduce bandwidth enough to allow someone to order a smaller pipe, that would be significant. But 20% or 34% of OpenLDAP tarball bandwidth is not significant to allow any such reduction. Hell, I doubt our service provider (the ISC, thanks!) would even notice such a reduction. It's a small percentage of our overall bandwidth usage, and our total a very small amount of their pipe. At official mirrors, I'm sure we're also in the noise. And at the downloader, it's only 5MB a pop. While one can argue that all those 1MB add up, I argue they don't add up to much. -- Kurt