Re: autobuilding and embedded timestamps
Wichert Akkerman <wichert@valinux.com>:
> Previously Edmund GRIMLEY EVANS wrote:
> > The trouble is that only the linux-kernel package, say, can know how
> > to ignore the timestamp inside a kernel image.
>
> Huh? I don't follow that logic. It's quite trivial to compare two
> packages and ignore the timestamps for the files inside them. Basically
> you extract and do a binary diff (or compare md5sums). You can script
> that in say 10 minutes.
You're still misunderstanding me!
The file "bzImage" contains a timestamp. That's what I mean by an
"embedded timestamp". It's the number of seconds in binary, if I
remember correctly; /sbin/lilo contains the date as text. I don't see
how a simple script could ignore those timestamps.
I agree that a simple script could unpack static libraries. On the
other hand, I don't suppose anyone has any use for the dates of the
archive members; ar x doesn't even extract the dates by default. So
why not zap them.
> > Why do you find those times to be valuable (more valuable than they
> > would be if they were replaced by the date of the source diff)?
>
> Because knowing when something is build adds extra information.
You still have that information in the dates of the files. I am
suggesting that the embedded timestamps should be zapped, not the
dates of the files.
Probably most packages don't contain any embedded timestamps.
The kernel's embedded timestamp is (I assume) used to generate the
date displayed by uname -a. Would it matter to you if this date were
the date of the source diff instead of the date the binary package was
built?
(It might, I suppose, be more correct, to use the date of the newest
file on which the package depends, which would correspond to the
earliest time at which the package could have been built. That would
be more historically correct.)
Edmund
Reply to: