On Fri, Jun 12, 2009 at 4:40 PM, Antonio Olivares <olivares14031 yahoo com>
> 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.
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:
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.