A more efficient up2date service using binary diffs

Rodd Clarkson rodd at clarkson.id.au
Thu Mar 10 02:20:02 UTC 2005


On Wed, 2005-03-09 at 12:05 -0600, Rex Dieter wrote:

> 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).

Or, you could generate one patch for each release (based on the release
before it) and then apply multiple patches.

So, if you have the following releases:

1.0.0
1.0.1
1.0.1.1
1.0.2
1.0.3

You would have four patches and someone updating from 1.0.1 to 1.0.3
would need to download and apply three patches which should still be a
huge saving over having to download a single RPM.

Yes, it would be more than just grabbing a single patch from 1.0.1 to
1.0.3, but probably not a lot different since changes are often made to
different parts of the file.  It would however simplify the number of
patches that need to be maintained while trying to achieve the objective
of making it faster for people on limited connections (or people who
just want to update quick) to do so.

If the system was really smart, it might look at the size of patches to
be downloaded, compared with the size of the RPM and then decide which
would be better.


Rodd






More information about the fedora-devel-list mailing list