Chris Lamb wrote:
> May I propose the following behaviour *iff* SOURCE_DATE_EPOCH
> is set:
> - mtimes are taken from stat(2). [The FS creator is responsible for
> ensuring they are reproducible, possibly by some "clamping" call
> to `find -newermt | xargs touch …`.]
> - atime is copied from mtime [as FS creator "can't" set that].
> - ctime is copied from mtime [ditto].
man 2 utime promises to set atime and xorriso tries to restore it when
extracting files to disk. But for ctime i know no portable method.
One needs to be filesystem ultra user to influence that one.
(E.g. operator of xorriso inside the emerging ISO.)
Looks like --set_all_file_dates is losing its only user even before it
Your new FS creator responsibilities dilute the radical decision to which
the crowd pushed me a few days ago. As it is now, it is the clearest
Export SOURCE_DATE_EPOCH and forget about any other time issues which
you don't create yourself by own xorriso arguments.
We can justify this behavior by pointing to program cp which, too, updates
all file times by default. Just that we set and hold the clock as we desire.
Ok. It is definitely too early for release. :))
(I understand we have time until end of september for Stretch ...)
> This seems less like a giant hammer of setting them all to target->now.
Until release we can reshape it to a screwdriver.
Afterwards i am restricted by general compatibility commitments.
I need to think where and how to implement the new proposal.
Probably it is worth regardless how SOURCE_DATE_EPOCH will finally
If it becomes an alternative to --set_all_file_dates then the user is
free to override a hammer SOURCE_DATE_EPOCH by the new optiom
--set_file_times_to_mtime (is this a good name ?).
> I am therefore not testing them from
> the "Debian" point of view and ACKs are simply my own testcases.
Any ACK or NAK is highly welcome.
Have a nice day :)
Reproducible-builds mailing list