A more efficient up2date service using binary diffs

[Paul A. Houle]

	I was thinking about this stuff four years ago when I couldn't get DSL at  
home and it was absolutely painful to update RH 7 (or was it 8?) with  
up2date.

	The most obscene case was that up2date made me download 20 megs of font  
files to fix a a bad configuration file.

	If we were designing this kind of system as if users mattered,  it might  
make more sense to make it files-centric rather than rpm-centric.  I  
really hate the idea of making the system count on having rpms available,   
because I'm not so good about keeping the original disks around.  (Plus  
the survival of optical disks is hit-or-miss.  I've had some disks that  
lasted 8 years after getting treated with moderate care,  and I've had  
other ones that I couldn't read after walking them across campus.)

	It seems just as feasable to send diffs of the ~files~ rather than diffs  
of the ~rpms~;  if we're going to go through the bother of implementing  
something like this,  it makes sense to make something that "just works"  
rather than another one of these things that almost works (or rather,   
works if you have the disks,  works if you are ready to pull the disks out  
if you have yum,  kinda might work if you have a network install,  maybe  
it won't work.)

       This should be thought of as an optimization.  If the files on the  
disk don't checksum match the rpm database,  we ought to download and  
install the new rpm.

----

	I've always wondered if the Red Hat Network would have been more  
profitable if it had been less wasteful of bandwidth.