Request for Comments: updating RPMs using binary deltas.

[Chris Adams]

Once upon a time, Lamar Owen <lowen at pari.edu> said:
> YES!  Somebody got it! (well, except the part about just installing the 
> changed files: we run afoul of problems if we blindly just install changed 
> files and assume the user has a certain package installed, which is why we 
> have to have the original RPM somewhere accessible).

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.

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

> Of course, if we _HAD_ the server resources to do so, the update client could 
> send the E:V-R of the package up to the server, along with a sum, and the 
> server could build the patch on the fly (or send down the fully cooked 
> update): but that would be way too much server to require for this purpose.

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

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.