Hello William, > As a point of reference, two of the three Fedora machines I run don't have a > CD-Rom, and none of them were installed from CD media. Since you want upgrade the package you probably have a reference rpm around, being CD, local copy or somewhere on your local network. > How does this help the problem of an overworked download server, then? > People on dial-up will get timeouts just as easily as people on broadband. > Notice how few rsync servers there are on the mirror list? Part of the > reason is that rsync can put a much larger load on the server. Any kind of > decompression and/or recompression will just make that worse. Yes, I thought of that just now. Rsync is not an option since it wastes too much cpu on the server side, so we should go for "smart patches" (do any needed de-/recompression on the client side). But the issues involved in rsync (rsyncabilaty of a compressed file, or better whether the used algorithm recompresses the patched archive unambigouasly (sorry for lacking vocabulary here)) are relevant to this issue. I am not sure how rpms are compressed, gzip, bzip2? To patch binary files inside signed rpms rpm needs to use a compression algorithm that meets the above condition. Or rpms could be compressed with gzip using the --rsyncable option, so xdelta's on the whole rpm are more efficient. Bye, Leonard. -- mount -t life -o ro /dev/dna /genetic/research