A more efficient up2date service using binary diffs

[Kyrre Ness Sjobak]

ons, 16.03.2005 kl. 15.31 skrev Nigel Metheringham:
> 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.

Why make it so hard, as to put the workload of generating the diffs to
the mirrors? As far as i understand, mirrors use some kind of script
(using rsync?) to copy the contnent of one served resource to their own
disk, and serve it from there. They copy the contnent of a directory
from one server to another, and serve it using a run of the mill
ftp/http-server, hopefully suporting byte-ranges.

So... Why should we put the load of generating the prpm's to the
mirrors? Why not do that on the main fedora update server - the one that
the mirrors mirror? Of cource, we could put them in a separate
directory, so mirrors could easily choose to mirror them or not. But
main point is: Do the "dirty work" of generating the prpms on the fedora
update server (or maybe even the build system).

Then upload prpms (newest version -2 -> newest version and newest
version -1 -> newest version and base-version -> newest version, to
cater for such things as "haven't updated in a while" and "somebody
shipped to updates to the package in one day") and the full rpms.

This way, yum can use the full rpm's the way it does today to get
headers from byte-ranges, and for those who doesn't want to store a lot
of base-rpm's on disk, for those who want to easily have a friend etc.
burn a disk of updates (some people just doesn't have any network), for
people installing new apps from scratch. When yum has decided what to
do, it downloads the prpm's (if the user has the base rpm, if not it
just get the full updated rpm), patches the old rpm lying on disk to
generate a new rpm, and install that as usual.