[Yum] Re: Recreating headers yields different files

[Axel Thimm]

On Mon, Apr 28, 2003 at 08:38:36AM -0700, garrick wrote:
> On Mon, Apr 28, 2003 at 05:32:46PM +0200, Axel Thimm alleged:
> > On Mon, Apr 28, 2003 at 11:08:00AM -0400, seth vidal wrote:
> > > On Mon, 2003-04-28 at 03:49, Axel Thimm wrote:
> > > > I observed that recreating the headers of the same set of rpms is creating
> > > > *.hdr files that are different in content. Does some date enter the *.hdr
> > > > files?

> > > it's not the rpm functions that are causing the variation - its gzip.

> > I think gzip includes the modification time of the included file. If the
> > modification time of the created hdr files were set to that of the rpm itself,
> > gzip would always yield the same result, and it would also make
> > rsyncing/caching the hdr files even simpler! :)

> Then what does gzip do when it reads on stdin?  (maybe that fixes your
> rsync problem)

it uses the current time. If you ask google for
http://www.google.com/search?q=gzip+modification+time
you get as the first document
http://www.ietf.org/rfc/rfc1952.txt
which describes the gzip format:

>      MTIME (Modification TIME)
>            This gives the most recent modification time of the original
>            file being compressed.  The time is in Unix format, i.e.,
>            seconds since 00:00:00 GMT, Jan.  1, 1970.  (Note that this
>            may cause problems for MS-DOS and other systems that use
>            local rather than Universal time.)  If the compressed data
>            did not come from a file, MTIME is set to the time at which
>            compression started.  MTIME = 0 means no time stamp is
>            available.
-- 
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/20030428/fab2f066/attachment-0001.pgp