A more efficient up2date service using binary diffs

[Eric Warnke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050316/114a6f27/attachment.sig>