Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same violations
in eg manpages"):
> 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).
I think you are suggesting that the upstream maintainers ought to
manually update the date. In practice I think very few upstream
maintainers (want to) do that.
As I've said, I agree with you that an automatically maintained date,
which simply reflects something about the build time, or overall last
source code update, is not very useful. It's probably a mistake by
upstream to provide it.
I think many upstreams just provide it because the conventional
manpage format has a field for a date in it. So they reasonably think
it must be there for a reason and they should provide a date.
Which is true, but the reason is from a time when (i) we would
frequently print out manpages *and* (ii) there would be approximately
one branch of the codebase, and (iii) the whole workflow was very
different - so in those days the build date was a useful proxy for the
recency of the information in the manpage.
As the author of a tool, Russ has the option to change the default
behaviour to leave the date out rather than using SOURCE_DATE_EPOCH.
Russ of course has to assess what the likely feelings of downstreams,
about that, are.
I think it would be worth trying to write up this position in an essay
or something and seeing how it's received. Or change the manpage
template and docs to say "don't put an automatically generated date
here". Anyway we're not going to be changing pod2man in trixie.
(In a modern dev workflow, it might be possible to automatically
obtain a file-specific date out of the git history. I don't think
that would be valuable enough to go to the effort, and it's not very
much help for us in Debian given our current source code management
practices. We certainly shouldn't be patching packages to do that.)
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
