Request for Comments: updating RPMs using binary deltas.

Lamar Owen lowen at pari.edu
Fri Jan 9 05:02:06 UTC 2004


On Thursday 08 January 2004 11:50 pm, Chris Adams wrote:
> No, you don't need the original RPM any more than you need the original
> RPM today.  All you need is the difference between the original RPM and
> the update RPM; rpm (or some mythical rpmpatch tool) does all the same
> checks (i.e. don't install if the package version(s) you update aren't
> installed, check for changed files, etc.) just like "rpm -U" does today.

Now this has me thinking.  If someone ONLY went through the regular updates 
channels, you might not have to have a baseline RPM locally, as long as what 
is actually installed is directly descended from the baseline and has only 
had the patches applied.  That's because each patch is cumulative; this is 
much like the way Windows Service Packs work.  SP6 for NT4, for instance, 
installs the same files if you are at SP5 and if you are at SP1.  Not a great 
example, but...

Chris, care to develop the idea a little more and show us why this would be 
the case for things as complex as the kernel source RPM?

> If you require the original RPM to be around, you've lost already.
> Given the choice between longer update downloads and keeping CDs ever at
> the ready (or on the disk), users will choose the most convenient (i.e.
> longer downloads).

Ah, but this is the crux.  I personally would (and do) keep the CD at hand and 
choose the shorter download.  I keep my install media with my laptop all the 
time.

>  Okay, actually users will choose to do nothing at
> all, but you at least have a chance that they'll download an update.  An
> update that requires original CDs or 2G of disk wasted will not fly.

Disk is cheaper than bandwidth.

> Anything beyond plain HTTP or FTP raw file transfers is asking too much;
> my mirror wouldn't be a FC mirror if I had to run anything else (it
> doesn't have the horsepower).

Yes, I understand.  That's why any diffs have to be premade, and the 
processing has to be at the user client and at the buildhost.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu





More information about the fedora-devel-list mailing list