On Jul 9, 2008, at 8:35 AM, Jeff Johnson wrote:

>
>> From: "Jeff Johnson" <n3npq@mac.com>
>> To: <rpm-devel@rpm5.org>
>> Date: July 09, 2008 08:02:41 AM EDT
>> Subject: Re: rsyncable gzdio
>>
>> Grrr, my 4th attempt at a reply without delivery ...
>>
>> On Jul 8, 2008, at 6:57 PM, Alexey Tourbin wrote:
>>
>>> On Mon, Jul 07, 2008 at 11:44:07PM +0200, Jeff Johnson wrote:
>>>>     - make gzdio.c standalone.
>>>
>>> BTW, I have rsyncable gzdio implemntation (this does not require
>>> patched zlib, one only has to call gzflush() at certain sync  
>>> points).
>>>
>>
>> I'd like to not carry internal zlib.
>>
>> You are absolutely correct that the --rsyncable issue is calling
>> gzflush() at
>> certain sync points.
>>
>>> It is known to work well.  Please review the patches and tell me
>>> whether you want it or not.
>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>> a=commitdiff;h=c761902b
>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>> a=commitdiff;h=f7b5ee1e
>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>> a=commitdiff;h=8d5e355e
>>> http://git.altlinux.org/people/at/packages/rpm.git?
>>> a=commitdiff;h=52b2499a
>>
>>
>> In summary, your patches are quite nicely done and extremely clever,
>> but I'm not
>> sure that RPMIO could/should use them, as I've tried to describe  
>> above.
>>
>> I'm most certainly willing to be convinced otherwise however.
>>

(aside) Apologies for possibly sounding waspish, but MobileMe deployment
as well as wrestling with neon transport is, well, more b0rkage than  
I can stand
in a single day.

I personally think I'm going to have to reimplement all of the  
compressors
as lightweight buffer compress/decompress methods that can be attached
to any RPMIO output as side effect, I see no other way forward atm.

So my concern about supporting your patches in "production" gzdio is
likely m00t.

So let's see if your patches work on HEAD. I've got your 1st patch  
ready to check-in,
feel free to check-in the others (or be lazy and wait for me ;-).

(aside) Also, please feel free to alter my check-in stylistically  
too. I have certain
fetishes, always preferring
     typedef struct foo_s * foo
over
     typedef struct foo_s foo;

I also tend to do
     p = _free(p);
rather than the simpler/cleaner
     free(p);
mostly because I've burned myself by refactoring (and forgetting
the error msg usage of p, which then points to already free'd memory)
that I tend to burn my pointers routinely.

But both of the above changes are just my fetishes ...

I can live with most anything written in C, the above is what I do  
(and why).

Nice & clever patches is mho still. The cpio tracking may have to be  
generalized
to tar, but perhaps not. What I really want to see is the bandwidth  
improvement,
I'm obligated to try to make *.rpm packages rsyncable even if no one  
has a clue,
but have not been able to interest anyone else in the savings for years.

73 de Jeff