Compressing packages with bzip2 instead gzip?
psusi at cfl.rr.com
Thu Jan 19 03:23:48 GMT 2006
John C. McCabe-Dansted wrote:
>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.
>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.
More information about the ubuntu-devel