Compressing packages with bzip2 instead gzip?

[Paul Sladen]

On Thu, 19 Jan 2006, John C. McCabe-Dansted wrote:
> On Thursday 19 January 2006 02:41, Paul Sladen wrote:
> > The big problem is that the server-side data also needs to be uncompressed.
> Just to be clear, we do not have generate any deb files using --rsyncable.

Assuming there is a small change and zsync, there are three options:

  gzip, treated as data:  Download ~100% of file
  gzip with look-inside:  Download ~30%-40% of file
  gzip with --rsyncable:  Download ~ 5%-10% of file

(zsync needs teaching where to find the start of the two zlib streams within
a .deb for the second two.  The .debs need repacking for the last one).

> > If bzip2 (a block encoder) is used, then identity points only exist every
> > 900kB.
> I don't think it is possible to use zsync for .bz2 files.

Zsync can be taught that restart points occur every 900kB, likewise zsync
could be taught to find the restart markers in LZMA, but there's even less
of those.  You have a choice of optimising for two cases:

  Smallest size of .debs on the CD image
  Least bandwidth used during a network upgrade

Pick either.

> My solution would be to just use bsdiff patches against data.tar and 
> control.tar.

This is O(N^2), right?  Whereas zsync is O(1).

Yes, 'apt-torrent' could be used to fetch the chucks (instead of partial
HTTP), once 'zsync' has figured out what they are.

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