Updating RPMs using binary deltas (demo)

Leonard den Ottolander leonard at den.ottolander.nl
Wed Jan 28 13:22:37 UTC 2004


Hello Alexandre,

> xdelta requires the server to guess right which version the client has
> on its end, and last I looked it was non-reversible.

I don't believe versioning is that much of an issue with the approach
that Michael presents. Just always delta against the original rpm that
came with the release, since everybody should have that one lying around
(except for the 1 in 1000 people that do an FTP install from a remote
server). Delete the last delta when a new update comes out, just like
there usually only is one update rpm available.

>   A simplistic
> rsync-based solution OTOH just requires hashes for every package to be
> pre-computed on servers and made available for download.

Rsync puts a load on the server, which is probably not what you want.
These delta's (have you tried these scriptlets yet?) can just be
downloaded. Patching is done at the client end, and the resulting rpm is
identical with the full version. The fact that rpm now uses the
"minigzip algorithm" blows all objections against using xdelta out of
the water. It's amazing.

These delta bundles have to be created only once and can be distributed
beside the normal rpms. The user can choose whether to download the rpm
and proceed as usual or get and apply the patch to the existing rpm
(which would save him about 67% of the download according to a
preliminary investigation by Toshio) if he is bandwidth challenged. You
don't even have to integrate this into up2date or yum yet, just make an
extra branch for deltas available in the FTP tree, so people who need
them can download them.

> The end result is that, if you don't have anything in your local tree
> to begin with, you can download whatever version of the rpm you're
> interested in and it just works;

As I mentioned above, the "local tree" should contain the initial rpm
for 99% of the users. No need to put any load on the servers.

Bye,
Leonard.

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






More information about the fedora-devel-list mailing list