Compressing packages with bzip2 instead gzip?
psusi at cfl.rr.com
Wed Jan 18 20:42:15 GMT 2006
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).
More information about the ubuntu-devel