A more efficient up2date service using binary diffs

Jeff Spaleta jspaleta at gmail.com
Thu Mar 17 14:30:09 UTC 2005


On Thu, 17 Mar 2005 09:44:34 +0100, Kyrre Ness Sjobak 
> So... Why should we put the load of generating the prpm's to the
> mirrors? 

Initially... proof-of-concept. The easiest path to full integration of
this into the build/release system is incremental.  Come up with an
implementation, or two.. find a few mirrors willing to work with you
to host the necessary serverside scripts... advertise the clientside
scripts... so people in he community can start chewing on it.  You are
going to have to take a layered approach to this initially, where both
the needed client and server side processes are essentially addons
that do not disturb the existing infrastructure and toolspace.
Expecting both the existing buildsystem and the existing distro tools
to spin up direct support for vaporware patch/delta package
implementations is most definitely out of place and only serves to
keep this discussion from moving forward.

You can talk till your blue in the face about what the ideal system
should like, but until people in the community who are interested come
up with a usable implementation that can be real-world tested,
continued discussion about how cool it would be if Fedora's
build/release/mirror system handled this is just navel gazing.  I
don't think I've seen ANY evidence that the people you need to
convince, who have some decision making power as to how the Fedora
build/release/mirror system operates are convinced this is worth it. 
And at this point I don't think further discussion without an
implementation of some of these ideas is going to change anyone's
minds.  Getting a sample server and client implementation out is your
best chance of seeing any progess on this.

-jef




More information about the fedora-devel-list mailing list