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
