Request for Comments: updating RPMs using binary deltas.

Pekka Pietikainen pp at ee.oulu.fi
Thu Jan 8 18:36:28 UTC 2004


On Thu, Jan 08, 2004 at 12:31:31PM -0500, Jef Spaleta wrote:
> Lamar Owen wrote:
> > The rpmdiff would be generated by the build process, and then the >
> rpmdiff would be uploaded.
> 
> I don't think that was really Seth's point. So let me say what i think
> his point was. How much extra space do mirrors have to supply to mirror
> the rpmdiffs an an OPTION as well as the fully cooked update rpms. Over
> the lifetime of Core, how many different kernel updates do you expect to
> see rolled out for example? How much space are you really talking about
> mirrors providing for the OPTION of using a collection of rpmdiffs over
> the accumulated lifetime of a core release. You can not get away from

> providing full rpm update packages. I'm certainly not prepared to
> entertain the idea that if I have a custom or alternative package
> version install that I need to downgrade all the way back to the iso
> release version then apply 7 updates. All those extra steps is bound to
> add extra fragility.
I think a reasonable assumption would be that to use patch rpms you need 
the original FC<x> media (low-bandwidth users should have these around),
and just have patch rpm for every errata.

As for the extra space, I hacked up a very quick prototype using xdelta and
this is the kind of bandwidth benefit one can expect:

-rw-r--r--  1 root root 16617596 Jan  2 23:42 kernel-2.6.0-1.23.i686.rpm
-rw-r--r--  1 root root 16608723 Jan  7 22:36 kernel-2.6.0-1.30.i686.rpm

run rpm2cpio.sh with the gunzip removed and you get 

-rw-rw-r--  1 pp pp 15931991 Jan  8 20:02 123
-rw-rw-r--  1 pp pp 15922711 Jan  8 20:01 130

[pp at connecting tests]$ time xdelta delta 123 130 xdelta1
 
real    0m8.791s
user    0m4.889s
sys     0m1.164s

-rw-rw-r--  1 pp pp 2144462 Jan  8 20:12 xdelta1

[pp at connecting tests]$ time xdelta delta --pristine 130 ../kernel-2.6.0-1.30.i686.rpm xdelta2
 
real    0m0.897s
user    0m0.802s
sys     0m0.067s

-rw-rw-r--  1 pp pp 179058 Jan  8 20:14 xdelta2

So a total of 2323520 bytes, which saves 86% in size.

Other data points:

kernel-source-2.4.22 -> 2.6.0 was 62% smaller.
kernel-2.4.22 -> 2.6.0 7% smaller (so really not worth it)

No idea what the average would be, but you can always use some threshold 
for bothering at all with the patch and that would be your worst
case scenario, 20-30% of total space tops would be my estimate.

-- 
Pekka Pietikainen





More information about the fedora-devel-list mailing list