On Mon, 25 Jul 2005, John Kohl wrote:

> I've always disliked using compressed tar format for packages anyway--it
> makes it inefficient to examine or extract components without reading
> the whole thing.  Last I looked at the package code (5+ years ago),
> unpacking and installing could take nearly 3x space (one for compressed
> tarball, one for unpacked copy, one for target install area if on a
> separate mounted file system).

As Curt mentioned, we want "single-pass" functionality anyway, so the 3x
space is a little moot.  It just requires proper processing to handle a
stream-based archive.

> If we're talking about serious rework of packaging for signing, how about
> switching to a zip or similar archive format with random access to
> members?

It's much more efficient to allow multiple files in the same distribution
archive to share a compression dictionary.

7-Zip, ACE, and "solid" RAR are becoming so popular in the PC world, as they
run circles around any random access format.  For just a cursory example,
take any large Java JAR that uses zip's -9 compression level (note that some
use -0 for mostly unfounded execution speed reasons), and gzip it -- it will
compress further yet, even though you're packing already compressed data.

There have been many repeated suggestions/requests to integrate libbz2 into
pkg_add so that packages can switch to .tbz format by default.  That's
another step away from random access, not towards.

(Note I haven't mentioned the Un*x file attribute capabilities of tar, as
Info-Zip has long since provided similar functionality in the Zip format.
It's the compression efficiency that really wins here.)

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>