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