A more efficient up2date service using binary diffs

Jeff Johnson n3npq at nc.rr.com
Sat Mar 12 18:17:24 UTC 2005


M A Young wrote:

>On Fri, 11 Mar 2005, Jeff Johnson wrote:
>
>  
>
>>This patch
>>    https://svn.uhulinux.hu/packages/dev/zlib/patches/02-rsync.patch
>>is in rpm-4.4.1 and on by default.
>>
>>If the payloads in FC4 are not rsyncable right now, then it's because
>>beehive is using an
>>older version of rpm ... checking ... yep, current rpm payloads should
>>be rsync ready:
>>
>>$ rpm -q --qf '%{rpmversion}\n' perl
>>4.4.1
>>    
>>
>
>It seems the option isn't active for FC3 and its updates (which is what I
>had tested) so I have repeated the test with a couple of RPMs from
>different rawhide mirrors using xdelta, which uses a similar algorithm to
>rsync, and found the following sizes
>  
>

Yep, rpm-4.4.1 is not in FC3, and so *.rpm payloads are not prepared 
with the zlib equiv of gzip --rsyncable.

>libgcj-4.0.0-0.31.i386.rpm 13942525
>libgcj-4.0.0-0.32.i386.rpm 13950302
>xdelta of rpms              6911651
>xdelta of header + cpio     3723074
>
>thus there is a significent saving in size for small changes, though you
>can do even better with more processing. Also from my experience with
>openoffice rpm library rpms don't diff as well as other packages, so the
>typical saving might be better than this example.
>  
>
Hint: xdelta is the wrong approach, because both packages have to exist 
on either client or (more likely) server,
leading to a combinatorial complexity of deltas to manage for all 
possible updates.

Try rdiff from librsync instead.

73 de Jeff




More information about the devel mailing list