pkgbase: Timestamp files with SOURCE_DATE_EPOCH

[jlduran]

Summary

Specify the modification time (mtime) of the files to match
SOURCE_DATE_EPOCH rather than the current time when creating packages.

PR: 294002

Test Plan

In preparation for NanoBSD + pkgbase. NanoBSD images have its base
files timestamped with NANO_TIMESTAMP, ensuring deterministic images.
Let's do the same for pkgbase:

% pkg info -R -x FreeBSD-\* | grep mtime: | sort -u
        mtime: <SOURCE_DATE_EPOCH>

[kevans]

Specify the modification time (mtime) of the files to match SOURCE_DATE_EPOCH rather than the current time when creating packages.

Can you spell out a little more clearly in the commit message why pkg's automatic SOURCE_DATE_EPOCH usage isn't sufficient here, please? By all accounts it seems like this should be a nop, so I guess it's that SOURCE_DATE_EPOCH isn't exported into pkg's environment in these targets?

[kevans]

(I think you can probably make an argument for .export SOURCE_DATE_EPOCH and a lot of these SOURCE_DATE_EPOCH=$(SOURCE_DATE_EPOCH) assignments can probably disappear, but maybe that's a discussion for another day)

[jlduran]

In D56070#1282516, @kevans wrote:

Specify the modification time (mtime) of the files to match SOURCE_DATE_EPOCH rather than the current time when creating packages.

Can you spell out a little more clearly in the commit message why pkg's automatic SOURCE_DATE_EPOCH usage isn't sufficient here, please? By all accounts it seems like this should be a nop, so I guess it's that SOURCE_DATE_EPOCH isn't exported into pkg's environment in these targets?

Yes, I tried to do exactly that in the bug report. But, I'll do that in the commit message as well. Thank you.
Note that I have no strong opinions on whether we should set the SOURCE_DATE_EPOCH environment variable vs. using -t, although I slightly prefer -t. My only objective is to actually timestamp all the files in the package.

[ivy]

i have a strong preference for using SOURCE_DATE_EPOCH here, if possible: it will avoid conflicting with some other pkgbase work i'm doing, and more generally seems like a cleaner solution as anything that needs that can easily consume it; this is information that should be generally available to the build system.

[jlduran]

In D56070#1282531, @ivy wrote:

i have a strong preference for using SOURCE_DATE_EPOCH here, if possible: it will avoid conflicting with some other pkgbase work i'm doing, and more generally seems like a cleaner solution as anything that needs that can easily consume it; this is information that should be generally available to the build system.

I'll update the patch to actually use the SOURCE_DATE_EPOCH env var. Thank you.

[ivy]

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.

edit: this is partly why i suggested using .export instead of editing the pkg commands.

[jlduran]

In D56070#1283471, @ivy wrote:

fwiw, i think this is fine to land before D56087 as long as you're only doing something like .export SOURCE_DATE_EPOCH in Makefile.inc1. that should be picked up automatically by the <bsd.pkg.mk> build.

edit: this is partly why i suggested using .export instead of editing the pkg commands.

Yes, that was the first thing I tried. For some reason I do not yet understand, it does not work (I even thought it was an issue with pkg-create(8) itself, after further testing, pkg-create(8) is working fine). I'll investigate further over the weekend. Feel free to commandeer this revision if you know how to fix it so that it uses the SOURCE_DATE_EPOCH from the env.