Compressing packages with bzip2 instead gzip?

[Paul Sladen]

On Wed, 18 Jan 2006, Phillip Susi wrote:
> Rather than generate the .zsync file against the .deb, it would be 
> generated against the uncompressed .tars inside the deb.

Yes.

> would require the server to either store the decompressed tars,

Incorrect.  A 'Zmap' is used, mapping uncompressed file-offsets to their
position in the compressed stream.  If you need byte X then you download the
compressed block from the previous restart marker to the next
restart-marker.

This is like on a hard-disk, if you need byte 813 you actually fetch the
whole of the second sector (512bytes) on the hard-disk.

By repacking the gzip you can add more restart-markers, lowing the
compression ratio, but increasing the frequency and granularity of the
restart-markers.  This makes the "sector size" smaller.

> Disassembling and reassembling the debs shouldn't be very difficult, and 
> zsync should work very well on the decompressed tars.

I think I'll just hack zsync to extend the Zmap table to support linear
mappings, and possibly bzip2 mappings, aswell.  It maybe be possible to
'trick' the existing decoder into doing a straight copy for the linear part
by letting it try to compress the stream, file to get the correct checksum
and resort to downloading raw instead.  A deb would look like:

  linear mapping (ar header, control.tar.gz, data.tar header)
  gzip mapping (data.tar)
  linear mapping (ar tail)

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