--hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 c= reating > > > > *.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=3Dgzip+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 =3D 0 means no time stamp is > available. --=20 Axel.Thimm@xxxxxxxxxxxxxxxxxxx --hHWLQfXTYDoKhP50 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+rU4vQBVS1GOamfERAhnaAJ0TtFF/Mdx6/Jxjf6T7PJcsmWZpOACgiIrX p3CP2mDVm9wFWXknB6xN2Vc= =ou9f -----END PGP SIGNATURE----- --hHWLQfXTYDoKhP50--
