Re: mtime of fresh .go

[Ludovic Courtès]

Hello!

Andy Wingo <address@hidden> writes:

> On Mon 19 Jul 2010 00:31, address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> writes:
>>
>>> On Fri 16 Jul 2010 10:07, address@hidden (Ludovic Courtès) writes:
>>>
>>>>   commit 535fb833b34dfc3cc11a679d39390b06fd7e9180
>>>>   Author: Andy Wingo <address@hidden>
>>>>   Date:   Fri Jun 5 10:51:21 2009 +0200
>>>>
>>>>       stamp .go with timestamp of .scm; a fresh go has same mtime of .scm
>>>>
>>>>       * libguile/load.c (compiled_is_fresh): Rename from compiled_is_newer.
>>>>         Check that the mtines of the .go and .scm match exactly, so we 
>>>> don't
>>>>         get fooled by rsync-like modifications of the filesystem.
>>>>
>>>> When packaging things “normally”, the .go has an mtime strictly greater
>>>> than that of the source file, so checking for equality doesn’t work.
>>>
>>> But when reinstalling code from a binary packaging system, sometimes the
>>> mtime can go backwards.
>>
>> Please forgive my ignorance, but can you give an example of how this can
>> happen?
>
> Well there are two cases really:
>
>  * RPM or Deb systems typically timestamp their files based on the times
>    they were built, not installed, and we don't have guarantees that
>    upgrading a package won't actually move the mtime into the past.

What matters is that the mtime(.go) >= mtime(.scm), and I’d expect it to
be preserved by packaging systems, even after an upgrade, no?

(My understanding is that RPMs/Debs are tar-like archives containing
meta-data such as the mtime, which is restored upon extraction.)

>  * When installing source code (via _SOURCES / _DATA), you don't have
>    any guarantees about the relations between the times of the SOURCE
>    and DATA files, *as installed*.

Apparently “make install” preserves mtimes on my system.  IOW, since
uninstalled .gos have mtime >= uninstalled .scms, the same holds for
installed .gos and .scms.

We’d need to ask the Automake people to check whether this is always the
case.

Thanks,
Ludo’.