Compressing packages with bzip2 instead gzip?

[Phillip Susi]

Aigars Mahinovs wrote:
> Only advantage of zsync over rsync is that there is no software
> running on the server side at download time. It is only nessesary to
> generate a .zsync file for every file to be downloaded by zsync. So
> server can not decompress the .deb.
> 

Rather than generate the .zsync file against the .deb, it would be 
generated against the uncompressed .tars inside the deb.  This of 
course, would require the server to either store the decompressed tars, 
or decompress them on the fly and serve them to the clients on request.


That way the client can extract and decompress the tars from it's old 
deb ( or hopefully rebuild them from the already installed binaries if 
they don't have the old deb ), zsync the tars against the server, then 
recompress and reassemble them into the new deb.

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


> The idea of zsync is that the client downloads (via HTTP) the .zsync
> file, uses rolling MD4 and MD5 checks to determine which parts of the
> local file are different from the file on server, and then uses a HTTP
> request for a part of file (from byte x untill byte y) to get the
> different chunks.
> 
> The problem is in the metainformation that has to be generated on the
> server side. The .zsync files contain would need to contain filenames
> of all files in the .deb, MD5 sums of every file and a rolling MD4 sum
> of every file (to detect parts of file that have changed) and (the
> hard part) they would also need to include some kind of information
> that the client could use to determine where this file will be located
> in the compressed .deb (address, in bytes).
> 
> --