Fresh Fedora 11 fetches 362MB+ of updates, where's deltaRPM?

[Fernando Cassia]

On Fri, Jun 12, 2009 at 4:40 PM, Antonio Olivares
<olivares14031 at yahoo.com>wrote:

>
> > The Fedora infrastructure team is trying to streamline the
> > process a
> > bit, but the fact remains that generating deltarpms costs a
> > lot in CPU
> > time and RAM usage, and the more deltarpms you generate,
> > the more time
> > it takes.
>

Hello? This is Red Hat we're talking about. I'm sure they're not short of
computers or CPU cycles to devote to the task.


> Maybe we'd be better off getting a combination of rpm compression with lzma
> ala OpenSUSE.
>
>
> http://www.linux-archive.org/fedora-development/109887-rpm-compression-format.html
>

I don't think so. The idea behind deltaRPMs is that is just 500 bytes
changes in a 50mb packages, you get the bytes that changed, not the whole
thing all over again.

>
> Rahul opened up an RFE/Bugzilla here already:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=441110
>
> I don't know why but I think I dont truly understand the deltarpm process,


Heard of bindiff and patchers? id software started using those for updates
to the "Doom" game back in the DOS days.

So basically if just 50kbytes changed (say a bug fix) in a 30MB+ wad file,
you downloaded a 70/100kbytes patcher that from the original file created
the new one, just applying the 50kbytes of difference to the source to
create the updated version.

I enabled it on a Fedora 10 machine at home and the updates-testing repo
> does not have deltarpms :(, I have to get big downloads and the purpose is
> defeated.


So you say that because the repo you're using does not contain deltaRPMs the
logic behind deltaRPMs is flawed and thus not worth using? Interesting
logic, yours.

FC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20090612/3a039503/attachment-0001.htm>