Opened 6 months ago
Last modified 6 months ago
#69976 new enhancement
Set ports tree timestamps based on commit times
Reported by: | jmroot (Joshua Root) | Owned by: | admin@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | server/hosting | Version: | |
Keywords: | Cc: | ||
Port: |
Description
In order to set SOURCE_DATE_EPOCH
consistently, base needs to know when the last commit to affect a port's directory happened. Of the possible solutions, setting the timestamps on the files after checkout seems simplest.
This can be done either with a tool such as git-restore-mtime or with shell commands.
Change History (4)
comment:1 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 6 months ago by jmroot (Joshua Root)
The definition of "the source code files" in other distros includes the equivalent of the Portfile and its files dir, not just the upstream sources. For example, in Debian an update that only modifies debian/control
will still add an entry to debian/changelog
and thus cause a new SOURCE_DATE_EPOCH
to be used.
comment:3 Changed 6 months ago by ryandesign (Ryan Carsten Schmidt)
I'm not very interested in what other distributions do; I'm interested in what makes sense.
I never imagined that the definition of "the source code files" might be in dispute, but let's do this. The source code is the code provided by upstream, and any patches or additional files we add to it. In other words, the source code is the contents of worksrcdir. It does not include the Portfile or the patchfiles or anything else in portdir.
I do not know much about Debian except that they do not do things like MacPorts does. Debian repackages upstream source code into a new archive. I have often seen upstream projects ship a "debian" folder; I guess for those that don't, Debian's repackaging would add that. The SOURCE_DATE_EPOCH documentation, which was written by a Debian contributor and is thus probably biased toward their needs and customs, mentions that they parse debian/changelog and use the timestamp of the last entry in it (not the changelog's timestamp). That's obviously inapplicable to MacPorts.
It would make no sense for the source date epoch to be changed just because someone made a whitespace-only change to a Portfile or changed the port's maintainer, for example.
comment:4 Changed 6 months ago by jmroot (Joshua Root)
While you might want to ignore whitespace changes (though currently the logic for cleaning partial builds doesn't), there are plenty of other Portfile changes that do change the build result. If we want to use the last commit that is considered significant, then we probably have to store something like FreeBSD ports' TIMESTAMP.
If OTOH we don't care about having timestamps that increase when and only when the build results change, but just having consistent results, well… using a fixed value is the most reproducible of all and is also very easy.
Why?
SOURCE_DATE_EPOCH
is supposed to be set based on the source code files; see https://github.com/macports/macports-base/pull/274. The timestamp of the Portfile or patchfiles is irrelevant.