[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26734: Snippets (even empty ones) of tar sources reset the timestamp

From: Ludovic Courtès
Subject: bug#26734: Snippets (even empty ones) of tar sources reset the timestamps of all files
Date: Wed, 03 May 2017 10:58:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Clément Lassieur <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>> Clément Lassieur <address@hidden> skribis:
>>> 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
>> in ‘core-updates’.
> Yes, but is there a way to test the patch on one package without having
> first to rebuild everything?

I would add a snippet in ‘gnu-make-boot0’, which is the first package
being built, and then run:

  ./pre-inst-env guix build -S --rounds=2 \
    -e '(@@ (gnu packages commencement) gnu-make-boot0)'

>> 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.
> Does that mean that symlinks will still have their timestamps changed?

No, that means symlinks will still have their timestamps unchanged.  :-)

BTW, what timestamps to we put on the modified files?  We want that to
be deterministic so we cannot use the build time.  We cannot use a date
in the future, either.  We cannot use Jan. 1 1970 either because that
means that modified files may now be older than the unmodified files,
which may break build systems; for the same reason, we cannot leave the
mtime of modified files unchanged.

Now that I think about it, it’s not clear to me what can be done without
breaking something.


>> ¹ Because Guile provides bindings for ‘utime’, which does not support
>>   setting timestamps on symlinks.
> If the guile binding doesn't support setting timestamps on symlinks, I
> guess we can still use another way, like a system touch.

Or we could add bindings for ‘futimes’.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]