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.
