jdieter at gmail.com
Sat Jun 12 15:48:44 UTC 2010
On Sat, 2010-06-12 at 16:35 +0100, Richard W.M. Jones wrote:
> On Sat, Jun 12, 2010 at 05:27:32PM +0200, drago01 wrote:
> > We don't generate deltas for packages with a size of >= 100MB ....
> > which kind of makes it useless for this case but it seems that delta
> > generation is to expensive to do for such large packages on the re-eng
> > boxes.
> It's because the program that generates the delta RPMs reads the whole
> RPMs into memory, according to:
> Anyone know if there's a genuine reason why it does it, or if it's
> just a Simple Matter Of Programming to fix it? (And can point us to
> the actual bit of code that could be fixed ...)
For the record, openoffice.org-core comes under the size limit for
deltarpm generation (which I think is closer to 200MB, but I may be
wrong), which means we normally *do* get openoffice.org-core deltarpms.
In my other email, I explained why we don't have them right now.
As for the reason why, deltarpm currently compares *all* of the
uncompressed old rpm against *all* of the uncompressed new rpm. This
gives you the best possible delta at the expense of memory usage. I
would like to allow deltarpm to split both old and new rpms into block
and delta each block separately, but it would involve some very creative
reworking on how deltarpm uses pseudo-files for all of it's work (see
cfile.[ch] for the pseudo-file structure).
I don't know if that's clear enough, feel free to ask if it's not.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100612/fef1ed6b/attachment.bin
More information about the devel