[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement)



lør, 10 03 2007 kl. 10:56 +0200, skrev Jonathan Dieter:
> On Sat, 2007-03-10 at 07:55 +0100, David Nielsen wrote:
> > Do we know how many packages on average that would apply to, it seems to
> > me that unless this actually saves us bandwidth in general cases rather
> > than just OpenOffice.org (which is big and hideous by nature) then it
> > might not be worth it for anything but cool value.
> > 
> > Has this been tried on something like the FC6 updates? Additionally what
> > are the impacts client side of doing this, I assume a certain overhead
> > in stitching the packages together is present.
> > 
> > Aside that the idea sounds really neat and once it's ready for testing
> > I'd love to give it a go.
> > 
> > - David Nielsen
> > 
> I have a local repository with all of Core + some Extras + some Livna +
> some FreshRPMS in it.
> 
> If someone had installed everything from my repository when I first
> created it, and then had do an update to the latest version of
> everything, they would have to download ~1.5 GB of updates.
> 
> If that same person had the yum-deltarpm plugin enabled, they would only
> have to download 638 MB.  That is *including* all the updates that don't
> have drpms because the savings isn't enough.
> 
> That means that we're looking at a savings of roughly 60%.
> 
> As for the rpm rebuild time, it's not that bad.  Most of the time seems
> to be reading the data from the hard drive.
> 
> Hope that answers your questions.

Thank you and might I add over the top on sexiness.

- David Nielsen

-- 
"Ridicule is the only weapon that can be used against unintelligible
propositions. Ideas must be distinct before reason can act upon them.” 
-Thomas Jefferson 

Attachment: signature.asc
Description: Dette er en digitalt underskrevet brevdel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]