Updating RPMs using binary deltas (demo)

Alexandre Oliva aoliva at redhat.com
Wed Jan 28 12:15:05 UTC 2004


On Jan 28, 2004, Toshio <toshio at tiki-lounge.com> wrote:

> He better defines my vague misgivings about the SuSE patch method and
> presents rsync as a transport method as an alternative (which people
> here have shot down as being too server intensive).

What's so server intensive about downloading pre-computed hashes from
the server, then downloading the missing chunks of the file with http
requests?  Doesn't look like a big deal to me.

The tricky thing is that, for improved savings, you don't want to
rsync the compressed bits, since those don't rsync all that well; you
want to rsync the uncompressed bits, and then re-compress on the
client.  This would indeed make it more CPU-intensive on the server,
and could pose some hurdles to make sure md5 hashes and signatures
still match after the transfer, but it should be possible to work them
out.

> I think that the xdelta method bridges these two approaches.

xdelta requires the server to guess right which version the client has
on its end, and last I looked it was non-reversible.  A simplistic
rsync-based solution OTOH just requires hashes for every package to be
pre-computed on servers and made available for download.

What I envision is an RPM downloading mechanism that takes advantage
of the pool of bits from an existing installation of a package
(possibly also seeded with bits from other packages in a tree).

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; if you already have another version
of the package, it will be used to seed the rsync hash pool and
hopefully speed the transfer up, and all of this has minimal impact on
the server (other than disk space for the hashes), as long as an
rsyncable version of gzip is used.  If regular gzip is used, then the
server would presumably have to cooperate with the client in
uncompressing packages to improve download savings.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer





More information about the fedora-devel-list mailing list