Updating RPMs using binary deltas (demo)

[M A Young]

On Wed, 28 Jan 2004, Nigel Metheringham wrote:

> I have just tried using a couple of large rpms (on the assumption that
> these should have more commonality between minor version tweaks than
> small rpms) rsync-ing an updated rpm onto the previous rpm.
>
> For a Fedora kernel rpm (kernel-2.4.22-1.2140.nptl.i686.rpm and
> kernel-2.4.22-1.2149.nptl.i686.rpm) there was effectively no speedup
> seen by pre-heating the destination file with its previous version.  The
> extra negotiation required was of a very similar size to the actual
> commonality between the packages.
>
> With the glibc-common package (picked as it was quite likely to have no
> changes, and particularly would not suffer from object file timestamps),
> there was a slight advantage - 1717760 bytes out of 11193793 were saved,
> but at a cost of 60674 in protocol overhead sending the hashes.

I think your figures are a bit misleading, because I suspect you were
rsyncing the plain rpms, which will always be close to the rpm size, as
you are basically copying the compressed cpio archive, and only doing
something clever with the header. Here are my figures (xdelta is the sum
of the two delta files, rsync is the sum of the download and checksums)
glibc-common 2.3.2-101->101.4
xdelta			113194+19199		=132393
plain rpm rsync		11624765+21598		=11646363
extracted cpio rsync	4775981+46772		=4822753
straight download				=12903889

kernel-2.4.22-1.2115.nptl.i686->2149
xdelta			5591072+30088		=5621160
plain rpm rsync		12774882+21586		=12796468
extracted cpio rsync	25674282+32848		=25707130
straight download				=12798261

The cpio rsync is of course only part of the traffic you would need to
download as it ignores the header parts of the rpm.

	Michael Young