[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26734: Snippets (even empty ones) of tar sources reset the timestamp
bug#26734: Snippets (even empty ones) of tar sources reset the timestamps of all files
Tue, 02 May 2017 15:00:16 +0200
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)
Clément Lassieur <address@hidden> skribis:
> I think the code is in guix/packages.scm (patch-and-repack). Here is my
> understanding of what happens: the presence of the snippet leads to 3
> 1. extraction of the archive,
> 2. modification of some files (because of patches or snippet),
> 3. compression of the archive.
> Step 3 sets all timestamps to zero so to avoid non-determinism in the
> archive. We obviously don't want archives to depend on the time of
> their creation. But I believe we should only reset the timestamps of
> the files we modified in step 2. Unmodified files should stay
> What's the point? Well, while working on the 0ad package, I realized
> that building with 32 cores would always fail with a snippet (even if it
> is empty) and always succeed without a snippet. It took me a few hours
> to understand this, and I put a comment in the 0ad package. Maybe it is
> a 0ad bug (some tricky race condition that depends of file timestamps),
> but I believe it is also a Guix bug: an empty snippet should not change
> in any way the binary output of a package.
Yeah I was bitten by the same problem recently.
> I tried to patch 'patch-and-repack', but it triggers a full
> rebuild... WDYT?
Right, it’s expected to trigger a full rebuild, so this should be fixed
I guess we’ll have to collect the timestamps of all non-symlink files¹
in step #1 and to reapply them with ‘set-file-time’ from (guix build
utils) after step #2.
Thoughts? Would you like to do that?
¹ Because Guile provides bindings for ‘utime’, which does not support
setting timestamps on symlinks.