Hello! Andy Wingo <[email protected]> writes:
> On Mon 19 Jul 2010 00:31, [email protected] (Ludovic Courtès) writes: > >> Andy Wingo <[email protected]> writes: >> >>> On Fri 16 Jul 2010 10:07, [email protected] (Ludovic Courtès) writes: >>> >>>> commit 535fb833b34dfc3cc11a679d39390b06fd7e9180 >>>> Author: Andy Wingo <[email protected]> >>>> 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’.
