A more efficient up2date service using binary diffs

Kyrre Ness Sjobak kyrre at solution-forge.net
Wed Mar 9 18:32:10 UTC 2005


ons, 09.03.2005 kl. 19.05 skrev Rex Dieter:
> Kyrre Ness Sjobak wrote:
> 
> > So if you do have this archive (FC5 anaconda install option - install
> > local rpm repository?), yum (sorry Seth...) would download the correct
> > patch, apply it to the old rpm in order to create a new, fresh rpm, and
> > then update using that?
> 
> Yeah, and then *every* revision of the rpm needs to be made available in 
> order to construct every possible patch (unless *only* patches from the 
> base rpm are ever released, which, IMO, would be bad in other ways).
> 
The alternatives are clearly step-by-step upgrades (cumulative -
requires less bandwitdh but more client processing) or base-to-all (more
to download but less cpu usage) upgrades. Having patches between every
posibillity would be insane at best.

So yeah, some change would have to be made to createrepo as well.

> This has been discussed ad-nauseum on this list before.  In short, it's 
> a *lot* of work, for *little* relative gain (at best).  It's not worth it.
> 
I you have ever had to keep a fc system updated using a 64 kilobit/s
metered dialup, you wouldn't call it a "little" gain. Mostly *i* was
able to update my laptop at school and then copy it over to apt's (i was
using apt at the time) cache and doing the installing, and then burning
cd's to other dialup-using friends with the updates once in a while, you
wouldn't call it a small gain.

But a request to the original poster (or anybody interested): could you
do a binary diff between two openoffice versions, and post how big they
where, and how big the diff is? Pluss which versions, and how many steps
(versions) between them?

As said, this method doesn't have to change rpm itself, as it generates
the original rpm on the users end.

Kyrre




More information about the devel mailing list