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

["Ahmed Kamal"]

Since Warren blew up my cover, please find more details at the project's hosted page :)
https://hosted.fedoraproject.org/projects/presto
As mentioned presto tries to be a sane implementation of a delta rpm update mechanism
The "GuideLines" part, describes replies to common failures in previous implementations, and why people thought presto was a bad idea

A delta rpm update mechanism also enables fedora to issue faster/smaller updates consisting of mainly translation/documentation updates as has been recently requested.

Progress has been a bit slow, mostly because my boss is keeping me busy, but as Jonathan mentioned, testing is what's mostly needed now! Basically, I'm thinking instead of just calling for testers, we can setup some sort of a regression which would setup a FC6 machine with out-dated packages. Run prelink on that machine (This has been causing us some pain). Then use yum-drpm to update the machine, and record any failures ... if it seems well, go ahead with public testing. What do you guys think?

And since this is the yum  ing thread, when I switched from ubuntu to fedora, I thought yum was molasses! Now, I've mostly forgot how fast apt-get was!

On 3/9/07, Jonathan Dieter <jdieter@xxxxxxxxx> wrote:

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@xxxxxxxxxx
>
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?

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list