Request for Comments: updating RPMs using binary deltas.

[Pekka Pietikainen]

On Thu, Jan 08, 2004 at 10:33:01AM -0500, Lamar Owen wrote:
> Over the past few days on the fedora list, I have participated in a discussion 
> about 'why can't we distribute patches instead of multimegabyte RPMs for 
> little changes'.
> 
> One of the other participants suggested that this would be better suited to 
> the -devel list, to which I agree.
> 
> What I am proposing:
> 
> 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 
> 2.)	Package and sign this file, calling it an 'rpmdiff' or something, using 
> the same basic rpm header structure.  This rpmdiff file also carries all the 
> header info that a traditional errata RPM would carry, including the entire 
> file list, but would not be directly installable by RPM (unless RPM is 
> modified to use deltas, but that may be unwieldy).
I've thought about this as well. I believe the simplest approach would
be to have binary patch blobs (generated with a rpmdiff utility),
that contain just hashes for the original and resulting rpm as metadata.
A database of these (and the patch file name) is grabbed by yum/apt to 
find out whether there is a patch rpm for the update it wants to install. 
If not, grab the full update.

After you grab the patch, you rpmpatch it to get the exact same updated (and
gpg-signed) rpm you would get by getting the entire thing, which you verify 
normally and complain if the thing isn't what you expected (a signed, valid
rpm)

A simple design that should work for rpmdiff is doing it in two passes.
First you get the cpio file from inside the rpm's, uncompress them,
do a xdelta/rsync/whatever diff. Another diff needs to be done between
the original rpm with diff applied (and the cpio compressed)
and the final one with signatures and the works.

If the end result is "too big" (which would happen e.g. if the contents
changed too much or the compression format changed), forget about the patch
and make the user grab the full update.

Did I miss anything obvious on why this wouldn't work? :-) 

-- 
Pekka Pietikainen