> On Mon, 2006-04-10 at 23:24 +1000, David Timms wrote: > > I haven't tried this but I thought I might: from my reading of > the rsync > > protocol, it can efficiently sync two identically named files, > even when > > the data moves around within the file. This is done by taking a rolling > > hash and comparing at each end. > > > > An rpm update for say FC5, would be very likely to have very small > > changes - ie bug fixes, but since compiles would otherwise be > the same I > > imagine it would be a good candidate for efficient rsyncing. > > > > I was thinking that the changes for even openoffice, or the > kernel might > > not be so great even between major release eg FC4 to FC5. Some > rpm might > > hardly change eg docs and tzdata, or the language packs for openoffice > > or kde etc. > > The problem is that even if it is a small change, all the source gets > recompiled, so the resultant binaries could be different, and different > enough to cause large amounts of little changes. This is because we > don't just spin the same binaries with say a new doc file or something > like that. Little changes just from a recompile add up quickly. > On the subject of bandwidth, would it be possible to produce install ISO images once a month that included latest updates? Images would be dished out by bit-torrent and for each install would reduce load on the main servers at time of first update. Alternately produce an update repository torrent with instructions to produce a local update repository. Each day a new tracker would be produced and used to update the local update repository. This could be automated as a script. Rob Mortimer (Some bloke) -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list