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
> [email protected]
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
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?
fedora-devel-list mailing list