Binary diffs for deb files

[James Hall]

On Tue, 2006-05-02 at 14:50 -0700, Matt Zimmerman wrote:
> This seems like a limitation of the implementation, surely the technique is
> extensible to these formats.

The problem is it doesn't currently work on deb files and its not clear
how much work would be needed to achieve this.

On Tue, 2006-05-02 at 14:50 -0700, Matt Zimmerman wrote:
> How much bandwidth would your proposed approach save, if
> the problems with it were addressed somehow?

Binary diffs on uncompressed content will achieve better results than
diffs on compressed content. Even with the --rsyncable options. Since it
will only save space when large chunks of gzip data are the same.

This link seems to show zsync is no more efficient than rsync -z 
http://zsync.moria.org.uk/paper/ch03s05.html

On Tue, 2006-05-02 at 14:50 -0700, Matt Zimmerman wrote:
> - The user doesn't have a copy of the original .deb from the installation
>   media (these aren't saved on the system)

Synaptic asks for the installation media, if none is given the new
version is downloaded in its entirety.

On Tue, 2006-05-02 at 14:50 -0700, Matt Zimmerman wrote:
> - The original installed package may have been superseded by a security or
>   bugfix update

This is solved by providing diffs between each package. Then towards the
end of a distos life, diffs between these packages and the next distro
are provided. All in the simple format:

packagename_oldversion_newversion_arch.diff (for example)

Diff's wouldn't *have* to be done for everything of course, maybe just
the most useful ones such as OpenOffice if server space is an issue. If
the client finds the diff they need is sat there, good stuff, if not,
the download is only as slow as it was originally.

On Tue, 2006-05-02 at 14:50 -0700, Matt Zimmerman wrote:
> - Users who incrementally upgrade during development releases

Why would this need special thought?

Making diffs between each version is the only way to substantially
reduce bandwidth. Security updates and text changes could be tiny.

Kind Regards,
James