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