lzma compression/decompression in bsdtar/libarchive?

bf bf2006a at yahoo.com
Wed Nov 26 02:08:41 PST 2008




--- On Wed, 11/26/08, Stanislav Sedov <stas at FreeBSD.org> wrote:

> From: Stanislav Sedov <stas at FreeBSD.org>
> Subject: Re: lzma compression/decompression in bsdtar/libarchive?
> To: bf2006a at yahoo.com
> Cc: "Ivan Voras" <ivoras at freebsd.org>, freebsd-hackers at FreeBSD.org
> Date: Wednesday, November 26, 2008, 3:04 AM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 25 Nov 2008 12:51:33 -0800 (PST)
> bf <bf2006a at yahoo.com> mentioned:
> 
> > Not so long ago (the end of April, this year) someone
> tried to switch 
> > ImageMagick to using lzma-compressed tarballs, and
> caught a lot of flak
> > from others who were unfamiliar with this form of
> compression.  If Tim
> > could integrate it with libarchive, I'm sure that
> it would be more 
> > favorably received.
> > 
> 
> Indeed, the main argument against was that you need an
> extra dependency
> to unpack these, and there's no point in requiring that
> as bz2 versions
> were available.
> 

While I can understand a reluctance to add another port to the
dependency tree, on my (slow) machine archivers/lzma occupies 169kb of
disk space when installed, and took only a minute or two to build from
source, while every time a ImageMagick distfile is downloaded,
about 3Mb of network traffic and disk space is saved by using the
lzma-compressed distfile rather than the bzip2-compressed distfile.  And
there are some further time savings in downloading and unpacking.  So I
think that there is a "point" to switching, even if you didn't agree that
it was worthwhile for just one port.  When you consider that comparable
benefits could have been gained for no further cost for scores of
additional ports by switching to lzma, the decision to revert to bzip2
doesn't seem so good. I might add that I have seen ports in the tree that
use gzipped tarballs when much smaller bzipped ones are available, and
ports that USE_ZIP when there are smaller gzipped tarballs available, so
there's more room for improvement.

Regards,
          b.


      


More information about the freebsd-hackers mailing list