Compressing packages with bzip2 instead gzip?

[Phillip Susi]

John C. McCabe-Dansted wrote:

<snip>

>Take for example tetex...3.3 -> tetex...3.4:
>
> Adding the --rsyncable flag did not help, with lookinside it required 30.8% 
>of the file either way. Using --rsyncable without lookinside (using the -Z 
>flag to generate the .zsync file), we had to download 43.6% of the file. 
>Using -Z without --rsyncable we had to download 87.6% of the file.
>  
>

Are you sure that zsync was looking inside the compressed stream?  Did 
you do this with the .deb or the .tar.gz?  It looks like zsync can look 
inside a .gz if you tell it to, but I doubt it is smart enough to look 
inside the .deb, find the two gzip streams, then open those up, which is 
what you want it to do. 


>To get downloads in the range 5%~10%, you basically have to use bsdiff.
>
>  
>

Right, indivudal binary diffs between two versions will be smaller than 
the amount of data rsync or zsync will need to send to change between 
those two versions, BUT you must keep a diff between each and every 
version, and clients can not skip a version; they must apply each 
subsequent patch to the old version they have to get up to date.  With 
zsync you don't have to store/download diffs between every version.  The 
clients also must still have the original unmodified deb, which they 
usually don't.  With zsync, they could approximately rebuild the 
original deb from the files installed on their system ( conf files and 
whatnot may be different ), then zsync it up to date. 

<snip>

>The bsdiff approach has two main advantages over zsync:
>- about four times less bandwidth required.
>- works with compression other than gzip.
>
>  
>

It only works with non gzip compressors if you decompress first, then 
compute the bsdiff against the uncompressed data.