[Yum] Re: Recreating headers yields different files

[Axel Thimm]

On Tue, Apr 29, 2003 at 11:50:25AM -0400, Michael Stenner wrote:
> Regarding gzip and timestamps:
> 
> On Mon, Apr 28, 2003 at 10:54:05PM -0400, seth vidal wrote:
> > it can be and if it can be done nicely in the code I will, but I don't
> > think it can be done that cleanly at the moment.
> 
> I talked with seth about this a little.  It is possible to do this in
> the yum code, but not cleanly.  The added complexity is probably not
> worth the modest benefit.  In case it's useful to anyone, I'm
> including a file that subclasses the gzip stuff and writes files with
> a null timestamp.
> 
> I'm also including a short script which nulls the timestamps in
> existing gzip files.   You should be able to do a 
>  
>   null_gzip_ts.py *.hdr
> 
> In your headers dir after each rebuild.  (there may be buffer length
> issues requiring you do  for file in *.hdr; do null_gzip_ts.py $file;
> done)

Thank you, I took the null_gzip_ts.py and now zero the timestamps after each
yum-arch. I already had a directory comparison tool, which sets the oldest
timestamp for identical files, so in combination I managed to have my hdr
files stop changing (contents and modification time wise), which makes caches,
rsync and logs happy (me, too ;).

I wish that yum-arch could do that without a workaround, of course,
e.g. timestamping the hdr files (both internally in the gzip header and the
file itself) with the timestamp of the originating rpm. yum-arch could even use
this to not bother extracting the header out of an rpm, if the corresponding
hdr file with the right timestamp exists (the evr is encoded in the name
anyway).

But that's only a wish, I am also happy with the workaround.

Did I mention I was happy? ;)
-- 
Axel.Thimm at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.baseurl.org/pipermail/yum/attachments/20030430/e93e5e84/attachment-0001.pgp