Request for Comments: updating RPMs using binary deltas.

Alan Cox alan at redhat.com
Thu Jan 8 21:19:24 UTC 2004


On Thu, Jan 08, 2004 at 10:33:01AM -0500, Lamar Owen wrote:
> 1.)	Use rsync or something similar to generate an incremental backup of the 
> patched, unpacked RPM, versus the original distributed RPM (this is not well 
> known how to do this, but rsync is capable of just copying files that have 
> changed: see the O'Reilly book 'Linux Server Hacks' hack #42).  The delta 
> must use the original, pristine,  as-distributed, RPM as the baseline for 
> this to not become unwieldy.  We would want the file deltas instead of the 
> whole changed files that an rsync incremental backup would provide.

You need to modify the base packages for this.

I'll regurgitate several years of history on the subject as best I can. I 
don't want to present this as an it can't be done, more as a condensed 
history to help people work out how to do it.

Problem 1:  Gzip files don't rsync well. bzip2 files I'm not sure of the
situation. Rusty did work with rsyncable dpkg files and along with Tridge
hacked up a gzip library that generated slightly larger rsyncable files.
That change was tested ages ago in rpm and broke stuff so went back out.
I don't know if anyone ever sat down and debugged it in full

Problem 2:  Where do you get the original package from ? The CD has been one
suggestion but JBJ pointed out that you can assemble an approximation of
the original package from the on disk data in most cases. The config files
might be a little different but most of the content is basically the same.

Problem 3:  Server resources. The rsync computation clobbers the server
compared to the overhead of just spewing bits. Given people are running
3000 vsftp sessions in parallel off big servers that is a concern.


Problem 3 seems to be the big unsolved today. In theory the other bits
are solved.





More information about the fedora-devel-list mailing list