On Jul 9, 2008, at 8:35 AM, Jeff Johnson wrote:
From: "Jeff Johnson" <[EMAIL PROTECTED]>
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
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
