On Fri, 2007-03-09 at 12:35 -0500, Warren Togami wrote: > 2) Ahmed Kamal has been working on a potentially sane implementation of > deltarpm for Fedora's yum. Theoretically, it would work as an optional > yum plugin. If the deltarpm is substantially smaller than an RPM > update, then the deltarpm is provided on a mirror. If the deltarpm is > not provided, then yum downloads the original RPM instead. If it > downloaded a deltarpm, it reconstructs the original RPM and uses GPG to > verify integrity just like yum would verify plain RPM downloads. > > Ahmed probably could use some developer and testing help. I've been > encouraging him to be more communicative about his project in order to > get more help, but I haven't seen any further outreach lately. > > Warren Togami > wtogami redhat com > I've been working with Ahmed and Michael Schroeder (the upstream maintainer of deltarpm) to track down some long-standing bugs in deltarpm, especially as it relates to prelinked binaries. These bugs were causing very odd problems while working with the yum-deltarpm plugin. We *think* we've found them all (the patches are in the latest Rawhide version of deltarpm in Extras), so I think we're at the point where what we really need is someone who would be willing to create drpms of all new packages in Core and Extras (there's a modified version of prunerepo that does all the work for you), and host them for us. To give you an idea of the savings we're looking at: * kdebase-3.5.5-0.4.fc6 => kdebase-3.5.6-0.1.fc6 = 3.5MB vs. 30.2MB * kdegames-3.5.5-0.1.fc6 => kdegames-3.5.6-0.1.fc6 = 740KB vs. 11.1MB * OO.o-core-2.0.4-5.5.3 => OO.o-core-2.0.4-5.5.10 = 8.7MB vs. 92.4 MB There won't be that kind of savings for all the packages, but a general rule of the thumb is that the bigger the package, the better the chance that we'll get a good compression ratio on the drpm. Ahmed, do you have anything to add?
Description: This is a digitally signed message part