Updating RPMs using binary deltas (demo)

[Pekka Pietikainen]

On Tue, Jan 27, 2004 at 12:16:38AM +0000, M A Young wrote:
> >I seem to be unable to patch with just the .cpio.delta. I need the
> >.delta to make this work. What is the saving here? And why do I need
> >minigzip instead of gzip?
> 
> You need both files. The first delta transforms one cpio file to the
> other. The second handles the header bits of the rpm such as signatures,
> specs, etc. and is comparatively small.
> 
> The reason why you use minigzip rather than gzip is that minigzip uses the
> zlib libraries like rpm does, and produces the same compressed image.
> gzip creates a different compressed image, which is fine if you just want
> a compressed image, but not if you want to reconstruct the second rpm
> byte-for-byte so that the signatures work, as even slight changes in the
> compression algorithm results in completely different compressed images.
Some very valid points about the user having to have the original rpm
(whatever that is!) were raised when I suggested the rpm2cpio & xdelta
a few weeks back. I think the approach that should be investigated is

Diff:

1. create cpio of non-config files inside old rpm
2. xdelta between that cpio and the cpio (with config files) of new version
3. xdelta between compressed-cpio-of-new-version and the new full rpm
4. Create metadata with hash of the original cpio

Merge:

1. Verify that non-config files of an installed rpm are ok, if modified grab
   the whole thing. 
2. Create cpio of non-config-files (probably need to revert prelinking!)
   Can grab it from the rpm too. Ensure hash matches the metadata for the 
   patch rpm.
3. apply patch1
4. apply patch2
5. verify rpm signature 

Still doesn't solve the "what will be used as the base version if there are
20 package updates during a release or will mirrors have to carry them all?"
issue, though.

-- 
Pekka Pietikainen