A more efficient up2date service using binary diffs

Kyrre Ness Sjobak kyrre at solution-forge.net
Mon Mar 14 18:39:24 UTC 2005


man, 14.03.2005 kl. 18.28 skrev Harald Hoyer:
> Rex Dieter wrote:
> > Yeah, and then *every* revision of the rpm needs to be made available in 
> > order to construct every possible patch (unless *only* patches from the 
> > base rpm are ever released, which, IMO, would be bad in other ways).
> 
> why?
> The server has the FC-3 released rpm, the newest update rpm, and the newest 
> delta from the released to the newest.
> 
> client checks for new rpm
> if there is a new one:
> 	if there is not a local released-rpm (maybe on CD):
> 		if there is an old update and old delta?:
> 			reconstruct the released rpm, by reverse delta		
> 			download the delta
> 			apply delta to the released-rpm > newest
> 			install newest-rpm
> 		else:			
> 			download the newest-rpm
> 			download the delta (to later create the released-rpm)
> 			install newest-rpm
> 	else:
> 			download the delta
> 			apply delta to the released-rpm > newest
> 			install newest-rpm
> 
> The update app could ask to insert the appropriate CD to get the released-rpm.

We can't make a system be dependent on using CD's. Either it uses old
versions stored on *disk* (anaconda install option - if you are on a
broadband, it isn't worth it. If you are on a modem, copy all rpm's to
some place), or it downloads the whole thing. Please no "please insert
CD 3!" "CD3? I did a network install?!?" "please insert CD3" "OMG!!!"




More information about the fedora-devel-list mailing list