On 12 June 2010 16:48, Jonathan Dieter <email@example.com> wrote:
> 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.
Clear as quartz - thanks Jonathan. I do indeed recall us getting
deltas on OO.org previously which is why I raised the question. I
think the presto plugin is a huge improvement to Fedora and provides
wins on so many levels that it really is something that needs fixing.
With any luck we will see this for RHEL and CentOS 6.
Yeah, I'd love to have the brain-fu to sort this but I'm afraid its
beyond my meagre intellect. Happy to pick off an item from someone's
Amazon wishlist to get this bumped up the priority list.
devel mailing list