Bug#1104854: binNMUs can cause ma-same violations in eg manpages
On Wed, May 07, 2025 at 08:08:11PM +0200, Simon Josefsson wrote:
> Russ Allbery <rra@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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: