A more efficient up2date service using binary diffs

Kyrre Ness Sjobak kyrre at solution-forge.net
Thu Mar 17 18:22:35 UTC 2005


tor, 17.03.2005 kl. 15.30 skrev Jeff Spaleta:
> 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

Of cource. This has to be given extensive testing before getting rolled
in as *the* way of doing things...




More information about the fedora-devel-list mailing list