Update patches versus full update RPM.

[Leonard den Ottolander]

Hello Lamar,

Let me start by giving a short summary of the issues I believe need to be 
tackled when implementing a patch update system for rpm's.

Rsync (like) update paths probably are not an option since they are too cpu 
intensive on the server machine.

If you want to update (s)rpms using patches that patch files inside the 
archive you have to deal with (= patch) timestamps and changeable data in 
both the archive (whether tar or cpio) and the compressed archive (gzip or 
other). Assuming gzip creates the same compressed file data (apart from 
header changes) on the same input you still need to rearrange file order in 
the archive and patch the header (timestamps etc) of the archive before 
compression, and patch the header of the compressed archive, or (patching 
the) sign(/ing) will fail.

Also there is the issues of the recompiled binaries, which will all have 
changed. I am not entirely sure how this affects the size of the diffs, and 
if necessary it can be optimized by use of specific algorithms.

All this has to be implemented inside rpm.

I am not sure of the efficiency of xdelta's on the whole rpm when using 
gzip with the --rsyncable patch on the archive inside the rpm. This would 
require rpm to use this patched gzip.

The SRPM update issue can be easily solved by setting up a repository that 
supplies (signed) patches and SPEC files. You don't have to recreate the 
"binary", signed SRPM, but you are able to verify all sources (reference 
SRPM and patches). The amount of required disk space is minimal compared to 
the SRPM's and it can only result in a decrease of bandwith requirements on 
the server.

> I haven't solved the signing issue yet.  Thus my request for comments in
> -devel.  The archives of that list are public; see a thread "Request for
> Comments: updating RPMs using binary deltas."

You don't happen to have an URL handy?

> As mentioned on that list, SuSE are distributing binary patches NOW.

I hadn't noticed that before, but after taking a look in /var/lib/YaST2/you 
I see you are right (although this scheme does not seem to work with the 
kernel). The approach SUSE takes looks a bit like the scheme I propose for 
SRPM's: The patch rpm's contain complete binaries for the files that need 
patching, so you can not reconstruct the whole signed rpm, but you have all 
the signed parts handy to reconstruct an unsigned but verified version.

I am not sure how the list of files that need replacement is created. 
Either by checking which binary files are affected by patching certain 
source files (by parsing Makefiles and the like), or easier, by patching an 
existing, built source tree and only packaging files that are touched by 
the build.

This scheme, in contrasting to patching the whole rpm or the binaries 
inside, should be quite easy to implement and it doesn't need reference 
rpm's to be available on the client. It could also easily be improved by 
distributing binary diffs instead of the whole files, assuming binary diffs 
can be made significantly smaller than the binaries themselfs.

Bye,
Leonard.

--
mount -t life -o ro /dev/dna /genetic/research