This has got me thinking, if the binary diffs are just byte range replacement from existing RPM's why store the new rpm and the diff files? Why not just include the range metadata information in the repo and then yum ( or whatever ) could use http/ftp byte range requests on the new rpm + the cached older rpm to build the new rpm. By storing just the diff metadata we get away without forcing a kind of double storage on the mirrors, we have no need for additional protocols, and I think it just simplifies everyone's life. Diffrence metadata will continue to drop as more "diff friendly" rpm's are built. Changes to the way diff's are done can also be kept as part of the metadata so that future releases can change diff format without breaking backwards compatibility. Cheers, Eric Nigel Metheringham wrote: >On Wed, 2005-03-16 at 14:06 +0000, Joe Desbonnet wrote: > > >>We have to set realistic expectations here. There seems to be some >>reluctance within Redhat to upgrade the current update mechanism. I >>doubt we will get any of their programmers working on it. >> >> > >There is an additional restriction:- > * It will be much harder to sell this if special software - > especially any server (which would likely give firewall problems > anyway) or web server plugin is required to support this. > >Remember that there are a load of Red Hat/Fedora mirror sites. Lots of >them do not get a lot of attention, and some of the biggest and best >connected would also be loath to putting extra software on to facilitate >this. > >So the ideal is something that just works with http and/or ftp. Byte >range fetches are probably OK (for http). Requiring an rsync server >would make things more difficult, although potentially do-able (but >remember that sometimes rsync paths are rather different to the http >ones). > > Nigel. > > >
Attachment:
signature.asc
Description: OpenPGP digital signature
