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
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.