Compressing packages with bzip2 instead gzip?

[Paul Sladen]

On Mon, 16 Jan 2006, Phillip Susi wrote:
> Which is why we want to use 7zip, since it is twice as fast at 
> decompressing as bzip2, and gets better compression. 

I don't think you can generalise like.  One of the (many) algorithms that
7zip selects between is bzip2, the other being bascially zlib with a huge
(out of spec) window size.

The reason that 7zip does better on jump-infested i386 code is that it runs
a pre-processor over the binary to convert relative jumps into absolute
values (and the absolute values are more likely to repeat).

I think there is a case for adding support for a post-processing stage to
dpkg/cloop (like PNG does with predictors).  Secondly, if bzip2 speed is a
problem, I suspect there is room for optimisation (refactoring, _not_
turning on --omg-faster) and using bzip2 compression with a smaller
windowsize (<900kB) if the difference is less than 1% in size.

(For perspective, one seek() on the CD image is going to cost about the same
as the difference in execution speed of zlib/bzip2).

Delta-debs on Mirrors.

For mirror distribution, my conclusion from 12months ago was that zsync
(pre-computed, client-size executed rsync) against the data.tar regenerated
by dpkg-repack is the way to go.

Since this would go into APT, dpkg stays clean and 

I like the idea in somebody else's email of only providing zsyncs against
files published on CD or the last 10days worth.

I think a *top* priority should be delta-diffs on the Package lists, but the
dapper-does-it-48-times-a-day churn on these is massive.

	-Paul
-- 
This country is covered in white fluffy snow.  Helsinki, FI