On Wed, May 07, 2025 at 08:08:11PM +0200, Simon Josefsson wrote: > Russ Allbery <r...@debian.org> writes: > > > In particular, what "timestamp inside artifacts from the source code" > > do you believe I should use? I do not have any special access to the > > upstream release date. Or is the argument that the upstream build > > system should explicitly pass the date for all man pages to pod2man? > > Yes, exactly! > > > This is at least theoretically possible but is often not that > > straightforward depending on the details of the build system (there > > are a *lot* of different build systems in play), and I'm not sure how > > realistic it would be to push that change out across all packages > > (which is why I tried to solve the problem in pod2man in the first > > place). > > I think that solution is covering up the real problem. I believe there > is no universal "right" timestamp to put in a man page that you can > guess from a generator tool like pod2man. I believe the timestamp is > part of the documentation, and IMHO should be provided in the input > files or on the command-line. > > Consider a simple package containing two man pages. One is for a tool > that frequently change and is re-factored and updated on every release. > The other is for a tool that has been stable and never has changed. > > I think using the SOURCE_DATE_EPOCH timestamp in both man pages is not > helpful. Doing so solves the reproducibility problem at the expense of > the purpose of the information (to tell when it was last modified).
Dates and timestamp are useful. SOURCE_DATE_EPOCH was developped in the context of reproducible build to allow to set meaningful dates. It is perfectly valid for debian/rules to set SOURCE_DATE_EPOCH to something more meaningful than the changelog date. By changing SOURCE_DATE_EPOCH in what is purported to be a 'binary-only upload' we are breaking the reproducible build semantic. I am afraid the only good option long term is to introduce a new variable BUILD_DATE_EPOCH as suggested by Andrea Pappacoda, that would be identical to SOURCE_DATE_EPOCH except for binNMU. If only dpkg need to understand BUILD_DATE_EPOCH at first, then it is doable. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
