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: > > http://lwn.net/Articles/329484/ > > 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. Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
