Hi everyone.  I'm filing this against policy but it's not clear which
package(s) need to be changed.  We might decide to change sbuild
and/or dpkg-source and/or dh and/or lintian; we might decide to change
individual packages and/or policy.  I have tried to capture the irc
conversation as I understand it.

Background: We usually use binNMUs for rebuilds.  That involves a
binNMU-specfic arch-specific d/changelog fragment which is logically
added to the source changelog.  That has the date of the binNMU
request.  (Let's call that the "bdate" and the original source package
changelog date the "sdate".)

Since #843773, SOURCE_DATE_EPOCH (henceforth, S_D_E) has been set to
the binNMU date in binNMUs.  (In normal uploads its set to the sdate.)
This is because otherwise we have this scenario:

libfoo_1_m68.deb contains /usr/lib/m68k-triplet/foo.so.  We ask for a
binNMU on m68k.  Now we have foo_1+b1_m68k.deb containing a
*different* foo.so.  If we set S_D_E to the sdate, then 1+b1's foo.so
has the same mtime as 1's foo.so.  This is a big problem because it
can mislead programs which rely on file mtimes as a way to detect
changes.

Examples of programs which rely on the mtime include backup systems
(which is how I noticed this) but also build tools like ccache and
make.  So reusing the sdate mtime might cause an attempted rebuild of
*another* program to not pick up the changed libfoo - potentially a
very serious (and hard to detect and debug) problem.

However, if S_D_E influences the *contents* of shared files in an
ma-same package, we end up with a ma-same violation.

Apparently this has happened in libopts25-dev, in manpages.


Requirements:

 1. *Contents* of shared files in ma-same packages must not change as
    a result of binNMUs.  If they embed a date, they must use the
    sdate.  Otheerwise it's a ma-same violation.

 2. Arch-specific files whose contents change in binNMUs must have
    new timestamps - ie, the timestamps must be the bdate.
    Otherwise tools like ccache and make can badly malfunction.

 3. Ideally, arch-specific files which are archives which embed dates,
    would embed the bdate.  Otherwise, build systems which use
    archive member timestamps for rebuild-needed detection will
    malfunction.  I don't know if any such build systems exist.


Options that I can see:

 A. Shared files in ma-same packages are not allowed to embed S_D_E.
    For example, no dates in libopts25-dev's manpages.  Other
    situations (eg, other docs) will be handled similarly.

 A.0. Implement the above by patching out the date requests in the
    manpages in the individual package.  (Dates in manpages aren't
    really very useful anyway.)  Add a lintian lint which spots a
    ma-same package with dates in manpages.

 A.1. Implement the above by having strip-nondeterminism strip all
    build dates out of all manpages.  (Does making this change involve
    an archive-wide rebuild to ensure we can do future binNMUs?)

 B. Set S_D_E to the sdate but use the bdate for file mtimes in
    the .deb.  We would need a separate solution for arch-specific
    archives containing mtimes (and IDK how we would even detect
    them - and detecting them seems like it might be important to
    avoid the bugs described in requirement 3).  Transition plan may
    be complicated.  Also how would the build obtain the *two* dates?

 C. Say that affected packages may not be binNMU'd, but instead
    require a no-changes source-only upload.  It's not clear how we
    would avoid cosntantly making the mistake of doing a binNMU
    anyway, producing an ma-same violation.


Ian.

Thanks for writing this up.

* Ian Jackson <ijackson@chiark.greenend.org.uk> [250507 13:45]:

I think we are already in this situation, and already varying files
in M-A: same binaries earn the affected packages an rc-bug.

I'll also propose another option, lets call it D:

Set S_D_E to sdate + an offset in seconds of int(binNMU-number).

BR,
Chris

Thanks for writing this up.

* Ian Jackson <ijackson@chiark.greenend.org.uk> [250507 13:45]:

I think we are already in this situation, and already varying files
in M-A: same binaries earn the affected packages an rc-bug.

I'll also propose another option, lets call it D:

Set S_D_E to sdate + an offset in seconds of int(binNMU-number).

BR,
Chris

Chris Hofstaedtler writes ("Re: Bug#1104854: binNMUs can cause ma-same violations in eg manpages"):

I don't see how this helps.  Rebuilds are arch-specific, so the binNMU
number can vary across architectures, just as the bdate can:
https://packages.debian.org/sid/libopts25-dev

[Re-sending to the bug rather than the debian-policy@ list, sorry for
the duplicate delivered to list subscribers]

They can, but according to the rules applied by dpkg/apt for multiarch,
instances of the same binary package with a different version number are
not eligible for co-installation, even if they are both M-A:same, so
it's OK for their contents to be different.

(Concretely, if you have a hppa foreign architecture on your amd64
system, you can't install libopts25-dev:amd64=1:5.18.16-5+b2 and
libopts25-dev:hppa=1:5.18.16-5+b1 at the same time.)

Various developers (ask the release team to) schedule binNMUs to align
release architectures' ma:same package versions where necessary,
especially during the soft freeze. I see that libopts25-dev is at
1:5.18.16-5+b2 on all release architectures, so this has presumably been
done.

For -ports architectures, it's up to the port maintainers to either keep
up with the binNMUs of release architectures or decide that multiarch
co-installation is not sufficiently important for the port.

     smcv

Simon McVittie writes ("Re: Bug#1104854: binNMUs can cause ma-same violations in eg manpages"):

Ah.  Right.

Gosh, this is all very complicated.

It seems anomalous that we (i) schedule binNMUs on each architecture
separately but (ii) they must all be aligned.  This leads to suggest
another option
   E. Always schedule rebuilds on all arches, so they all
      have identical bdates.
(this may be quite hard or a bad idea for other reasons).  And of
course we have:

   F. Abolish binNMUs and just do no-change source-only uploads.
      tag2upload might make this much easier...

Anyway,

I think that means Chris's option D would work.  I have to say this
addition of +1 second feels like a bodge to me, although I can't
immediately think of a way it would go wrong other than merely
confusing humans.  (If we go with this option we should maybe pick a
larger value of 1 - aren't there some filesystems with >1s timestamp
granularity?  2 might be better.)

Ian.

We need to consider the trixie freeze:

Ian Jackson writes ("binNMUs can cause ma-same violations in eg manpages"):

I think the only ones that are acceptable right now (including of the
D E and F mentioned later in this bug), given that toolchain updates
are out of the question, are these:
...

Ie, declare this, in some sense, a mistake in how we've handled
libopts25-dev.  I don't think C is attractive because it leaves a
footgun pointed at the security and stable teams for the life of
trixie.

As Chris observes, this is the de facto situation.

I suggest therefore that for now we patch the dates out of the
manpages in this package.

We can keep this bug open for choosing a longer-term answer.

Ian.

not that it matters much (see below) but I think i had proposed this
on irc earlier :)

yes, it is. so thanks for writing this up.

I *believe* this is not done (always) because not all architectures always have
enough capacity...

(yes but we don't have that yet.)

yes :)

and now I wonder again why S_D_E plus (offset multiplied by something)
is better than what we have or had, which is a new d/changelog entries
for binNMUs causing an entirely new S_D_E for those binNMUs?!?

Hi,

That bug was triggered by Ian's mail in 2016 here:
https://lists.debian.org/msgid-search/22562.21637.415611.768269@chiark.greenend.org.uk

Until we get rid of binNMUs, I thought the workaround was that missing binNMUs
get triggered for packages that somehow got out-of-sync before the release to
get them back in sync for the release? wanna-build can send the binNMU
changelog entry including the timestamp to sbuild so that the same timestamp is
used across all architectures. This includes potentially incrementing the
timestamp by a second for each binNMU number so that backups do not break.

I thought we had "fixed" the problem this way a while ago and in cases like
libopts25-dev just some more binNMU scheduling was the answer?

Thanks!

cheers, josch

My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the
timestamp inside a man page.  This is just one of many symptoms that
will arise from trying to use SOURCE_DATE_EPOCH in an upstream context.

It seems generally better if upstream derive timestamps inside artifacts
from the source code for that artifact, or the last upstream release if
tracking the source code is problematic.  Then these timestamps will be
stable during all future rebuilds of the same artifact.

In this case, is the problem triggered by this line?

https://salsa.debian.org/debian/autogen/-/blob/8b4268fa779deaba862a7938ee0d5f051860d8e7/debian/rules#L11

If so, the problem is not in upstream but in the packaging.  A more
relevant timestamp to use appears to be the last upstream release
timestamp, or the timestamp from debian/changelog (sdate, not bdate).
Using SOURCE_DATE_EPOCH here seems just wrong on a conceptual level.

I mentioned this earlier:
https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20250120/014989.html
and gnulib provides a mechanism to derive a timestamp for source code:
https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00007.html

/Simon

* Holger Levsen <holger@layer-acht.org> [250507 17:16]:

Yes, sorry. Option D is "Holger's Option D".

So:
+b1 gets sdate + 1
+b2 gets sdate + 2
etc

Thus, it is entirely predictable, and as long as the binNMU
revisions are aligned across archs (as they must be), it should
work.

Chris

* Johannes Schauer Marin Rodrigues <josch@debian.org> [250507 17:58]:

Is this timestamp-sending implemented?

The changelogs look like this:

autogen (1:5.18.16-5+b2) sid; urgency=low, binary-only=yes

   * Binary-only non-maintainer upload for amd64; no source changes.
   * Rebuild for PAC/BTI support

Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same violations in eg manpages"):

If we're editing thie package, I think we should just get rid of the
timestamps in the manpages rather than trying to control more sensibly
which (sort-of-fake) timestamp we put in there.

Those dates in manpages are not really useful - they're a relic from a
time when one would print manpages out and want to know if the
printout was too out of date.  The source-code-last-touched date is
not very useful any more even for that niche use case.

Ian.

I think there is at least rough consensus that binNMUs are not great and
what we ideally want is changelog-only sourceful uploads instead (as
seen as foo_1.2-3build4 in Ubuntu), but only if that can be done without
making the release team's job harder.

If we want every .dsc file to be signed so that it has an audit trail,
then a changelog-only sourceful upload of 1000 packages[1] requires
someone or something with upload access to generate and sign 1000 .dsc
files, which is going to take a while (I certainly wouldn't want to do
that using a hardware cryptographic token, especially one that is
configured to require a touch or PIN per signature).

I don't think tag2upload is necessarily going to help here, because
making and tagging 1000 git commits doesn't seem a whole lot easier than
making and signing 1000 .dsc files, even if they all happen to be for
packages that already exist in a tag2upload-compatible git repo. A
different automated tool whose security model is less like "the original
git commit was signed by someone with upload rights who could equally
well have prepared the .dsc themselves", and more like "the
actually-source package was obtained from the archive, and the automated
tool has verifiably only added one more changelog entry at the top"
could maybe help?

(Or, thinking slightly more outside the box, a new dpkg source package
format variant that consists of the files of the actually-source
package, or an equivalent tag2upload-style tag, plus a machine-readable
instruction of the form "please rebuild a list of packages that includes
this one, with the specified changelog entry"?)

     smcv

[1] a somewhat extreme real-world example: I count 1063 distinct source
     packages in
https://lists.debian.org/debian-release/2025/04/msg00074.html

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

In some upstream packages I put the version number in that field, which
at least provide some of the out-of-date protection.

Help2man's default behaviour to use SOURCE_DATE_EPOCH is not helpful
here, IMHO, and will cause similar breakage over time unless people
override the behaviour (which I do in some upstream packages).

/Simon

Hi Ian,

I'm not really proposing any solution here, as I don't have the
experience to do so. Still, to answer your question about obtaining the
two dates, what about introducing a new variable BUILD_DATE_EPOCH which
is normally set to the same value of SOURCE_DATE_EPOCH except for
binNMUs? Build tools would then do the "right thing" (whatever it is).

Just a thought.

Bye!

Simon Josefsson <simon@josefsson.org> writes:

I am the maintainer of one of the main documentation generation tools that
does this (pod2man). I used to do it the way that you prefer and changed
to SOURCE_DATE_EPOCH to fix reproducibility problems at the request of the
reproducible-builds team.

I'm happy to try to address this problem in the generator, but this is the
opposite of the direction in which I thought we were going, so I want to
really understand the shape of the problem before making more changes. 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? 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).

Simon Josefsson <simon@josefsson.org> writes:

There are two standard footer locations for this kind of information in
UNIX man pages, one of which is traditionally used for the version and the
other of which is traditionally used for the date. I assume you don't mean
that you put the version number in both places. What .TH structure do you
use?

the build date with source_date_epoch based dates. (while obviously striving
to drop dates and replace them with version numbers...)

I'm not sure I understand what you mean.

the (last modification date of the) source code of the artifact has been
changed, i'm not sure why you expect stable artifacts built from changed source.

to be clear (and as just expressed in another mail to this thread), I don't
think we want to reverse the direction where we have been going.

I am all for removing timestamps where they provide little to no value!

Do tools handling man pages work without a date? I seem to recall trying
this in the past and the man command spit out all sorts of errors...

live well,
  vagrant

That's not an extreme example.

For the regular "Rebuild for outdated Built-Using" binNMUs by the
release team, rebuilding 1k source packages is not an uncommon number.

cu
Adrian

Vagrant Cascadian <vagrant@reproducible-builds.org> writes:

Yes, you can suppress the date by passing an empty string into the
appropriate argument to .TH. You can see this behavior with:

    pod2man --date "" /usr/share/perl5/boolean.pod | nroff -man

Russ Allbery <rra@debian.org> writes:

Yes, exactly!

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).

/Simon

Holger Levsen <holger@layer-acht.org> writes:

I don't think the purpose described in the specification for
SOURCE_DATE_EPOCH matches the use case here.  It seems there is push to
use SOURCE_DATE_EPOCH timestamps in places where that timestamp is the
wrong value, just for the sake of reproducibility.

I agree replacing it with version number is better.  Or just remove the
information completely, the cost to maintain this variable information
(and dealing with breakage like this) is probably not worth the small
benefits for humans to easily tell what version of a manpage they are
reading.

I meant that the timestamp field in a manpage is something that should
be coming from upstream in the same way that the text of the manpage is
coming from upstream.

I don't understand, can you elaborate?  Looking at the code here, my
reading is that debian/rules put the date of binNMU into
SOURCE_DATE_EPOCH and that ended up in the manpage, causing ma-same
problems.  There is no source code change.

What I would prefer is that the timestamp in the manpage corresponds to
the change time of source code involved in generating that particular
manpage.  It may be different for each manpage.  Yes, I know this is not
easy to implement (and many people will refuse to do it), but practical
obstacles doesn't take away that this seems like a better solution.

/Simon

Simon Josefsson writes ("Re: Bug#1104854: binNMUs can cause ma-same violations in eg manpages"):

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.

Simon Josefsson <simon@josefsson.org> writes:

Okay, I can see the appeal of that. I don't think I can help achieve that
goal as a maintainer of the generator program, though, unfortunately.
There isn't really a lever that I can pull to push things in that
direction other than forcing a date to be provided as part of the
interface, which is an extremely backward-incompatible change that would
break the world and therefore isn't really feasible. There is already a
flag for people to set the date if they want to, but they have to use it.

Another option is to follow Ian's suggestion and just remove the date
entirely by default. I suppose I could make that change in the generator
program and it *probably* wouldn't break anything that significant, but
it's the sort of change I'm a bit leery about making because I don't have
any good way of polling what my downstream users want and pod2man has
added the date for about 30 years. That's a lot of time for it to become
accidentally load-bearing, or at least strongly desired, by someone.

For whatever it's worth, with my upstream hat on, I think the behavior
that I would ideally want is for both man pages to receive a date matching
the last release date of the package. I understand why someone might
instead want it to be the last change of the tool, but I prefer to bump
dates and versions with releases even if there wasn't a change affecting
that program, in large part for the practical reason that figuring out if
there was a change to the tool is often annoying and tedious and I would
rather spend my development cycles on something else.

Either way, I agree that's not what we get with SOURCE_DATE_EPOCH right
now. The SOURCE_DATE_EPOCH behavior was a replacement for the previous
behavior of always using the mtime of the file, which has even more
problems including obvious reproducibility problems. I realize this may be
plastering over a bug, but I would argue that it was a pretty good plaster
that got us a long way with a minimally-invasive change. :)

If someone wants to tackle fixing all the build systems to make release
date information more readily available, that would be great, and I would
be very happy to use it in my packages. (gnulib is a good start!)

I'm not seeing how we can readily add this at the Debian packaging step,
though, so I don't think this helps with the more immediate problem.

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

I personally as a consumer of man pages find the date valuable to the
extent that it matches the last release date of the package. It gives me a
very quick feel for the age of a program and therefore for the likelihood
that it is being actively maintained. This is lossy and often wrong, but
it's right often enough that I do think it provides me with some useful
information that the version number doesn't.

That's part of why I'm reluctant to drop the date entirely, in addition to
my worry that someone may be relying on it for something I didn't
anticipate.

The Python setuptools-scm package takes an interesting approach to this
for version numbers that I rather like and that works for both Git
checkouts and distribution wheels, and one could imagine doing the same
thing for dates as well, but the hard part is incorporating this into the
upstream workflow. It's not really something Debian can do directly.

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,

Russ Allbery <rra@debian.org> writes:

.TH "tld_check_4" 3 "1.11" "libidn" "libidn"

So this puts the version number in the timestamp field and the project
name (without version number) in the field where the project name and
version number usually goes.

https://manpages.debian.org/bookworm/libidn-dev/tld_check_4.3.en.html

Btw the rendering of .TH lines at manpages.debian.org doesn't seem very
good and doesn't match how 'man tld_check_4' look.

Reviewing this now, I think a slightly better .TH for this man page
would be something like:

.TH "tld_check_4" 3 "1.11" "libidn" "Libidn Programmer's Manual"

/Simon

You are assuming SOURCE_DATE_EPOCH is set to the changelog date, but it does not
have to be the case. SOURCE_DATE_EPOCH is just a way to communicate the date to
the tool. pod2man or html2man not honoring it would be a bug.

It is frequent for debian/rules to set it to the date in the upstream
documentation so that the generated documents are identical to the one in the
upstream tarballs.

Having reproducible builds allow for meaningful date and timestamp, and is not
a rationale to remove them.

Cheers,

The source code for debian packages includes debian/changelog and other
files in debian/ ... which could include patches to the manpages or
otherwise affect the downstream artifacts... so the upstream timestamps
could potentially be misleading in some cases.

That code appears to work as intended, though there appear to be some
problematic interactions with multi-arch:same packages and binNMUs which
may have differing debian/changelog entries for the "same" binNMU
version across all architectures...

When building Debian packages, SOURCE_DATE_EPOCH is typically set from
debian/changelog... so I am not sure why you are objecting to
SOURCE_DATE_EPOCH here if setting the timestamp from debian/changelog
seems ok to you.

The whole point of SOURCE_DATE_EPOCH is to set a value that upstream
code and tools used in build systems (e.g. dpkg-buildpackage,
debian/rules, gcc, etc.) can consume to use a consistent timestamp,
without having to get into the specifics or internals of each individual
build system; each build tool or build system can consume
SOURCE_DATE_EPOCH and produce appropriate time related data in whatever
way is appropriate for that tool or build system.

Though of course, timestamps are best avoided, and SOURCE_DATE_EPOCH is
best used as an option for when there is no way to avoid a timestamp.


live well,
  vagrant

sigh. it does. I'm saying this as one of the authors of said specification
and a user of it for around ten years now.

(there might be a bug in how binNMUs set it currently, but this whole
side discussion is very time consuming and distracting. so i'm not calling
it a day without expanding further.)

Russ Allbery <rra@debian.org> writes:

Your flag is all you have to do in pod2man to help, I think.  It would
be nice if help2man had a similar flag.  Then maintainers who care about
this problem can opt-in to provide the timestamp they prefer (or opt-in
to go with tooling defaults).

Alas, there is probably no general recommendation that we can make here.
Some people want to have timestamps, some people prefer not having them.
Some people want the timestamp to correspond to the last modification
time of the tool or text, some want it to match the least release of the
package, and some want it to match SOURCE_DATE_EPOCH which merely
transfer the problem to picking the appropriate value for
SOURCE_DATE_EPOCH (build time?  debian/changelog time?  git commit time?
Debian stable release time?).

/Simon

There is a lot to unpack in that "whatever" ...

How many compilers, toolchains or other tools would now have to support
yet another environment variable?

What does having another variable actually accomplish that cannot be
accomplished by a single variable?

live well,
  vagrant

How so? We're changing the build environment (that's the point of doing
a binNMU) and the version number (because otherwise our systems wouldn't
upgrade to the rebuilt package) so of course we expect the result to be
different.

     smcv

That would not be workable.

For the not uncommon "binNMU 1k packages" case this would not only have
the signature problem Simon mentioned, it would also require downloading
1k git trees, some might have GB size.

dak already has all sources, a realistic solution for this problem
would be a dcut command that sends a file with lines
  <package> <version> <changelog entry>
and then dak creates source packages from that.

cu
Adrian

Simon Josefsson <simon@josefsson.org> writes:

[...]

I would recommend at least considering:

.TH "tld_check_4" 3 "libidn" "1.11" "libidn"

(or "Libidn Programmer's Manual" if you really want but I don't think the
extra words add anything).

What goes into what part of the footer is not very standardized, so it
probably doesn't really matter, but this puts the version in the left
bottom footer, which is reasonably common, and puts the package name in
the center of both the header and the footer, which is pleasingly
symmetric at least to my eye.

Another option would be:

.TH "tld_check_4 3 "" "libidn 1.11" "libidn"

which leaves the center footer empty.

I just noticed this note that I wrote down a long time ago and forgot
about. I'm not sure if this is still an issue on any platform that you
care about.

    Note that some system "an" macro sets assume that the centered footer
    will be a modification date and will prepend something like "Last
    modified: ".

I vaguely think this was a thing on Solaris at some point? But I'm not
sure.

This suggestion is based on assumptions that are not true.

At the wanna-build level you can schedule only a binNMU for one
architecture, higher level tools that schedule rebuilds on all
arches do therefore emit one binNMU command per architecture.

It might be possible to hack together a solution for what you want,
but that would still not solve the other problem of binary-all binNMUs.

As already mentioned, the proper solution for binNMUs would be at the
dak level with a dcut command[1] - then you have a proper new source
package with a new source version and everything will just work
without additional hacks.

cu
Adrian

[1] or some dedicated service, so that the requester of a 1k package
    binNMU does not have to download sources for 1k packages and does
    not have to sign 1k packages

Precisely, SOURCE_DATE_EPOCH was introduced to make builds more reproducible.
and not to solve the binNMU problem which predates reproducible builds by a
long time.

Cheers,

Hi!
[…]

Most of this was already covered in for example
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#132, or in
the referenced megathread where the compromise to reintroduce
the Multi-Arch:same ref-counting was reached due to popular demand.

The root problem for all of this is still though, that Multi-Arch:same
ref-counting is an apparent convenience that avoided the up-front
cost of package content splits and making copyright and changelog
files proper dpkg metadata (in the .deb control member), that we have
instead been paying with at least, less robustness (the timestamps and
contents issues), more difficult dependency resolution and transitions
(version lockstep), and breakage on existing very convenient mechanisms
(like binNMUs).

The SOURCE_DATE_EPOCH issue reported here, and multiple other
arguments brought up in the bug report / thread, look like a
distraction to me. I agree with Russ that using that for the date in a
man page is perfectly fine, and I'm happy I don't have to manually track
release dates manually any longer. The problem is that the co-installable
ref-counting is just fragile. Even w/o binNMUs (which are also getting
IMO unjustly blamed here), a package might end up with different contents
for ref-counted files if the builds happen at different points in time.
To use an example brought up in the thread, if foo_1.0_amd64.deb gets
built at time T+0 and foo_1.0_armel.deb gets build at time T+1, where
they use a different pod2man version that generates different output,
then regardless of SOURCE_DATE_EPOCH we also get a M-A:same file
conflict (this was known at the time of the compromise).

The binNMU idea/mechanism also seems generally fine, the way it has
worked historically is "just" :) not compatible with M-A:same
ref-counting. In their current form, they pose problems due to the same
binNMU revision being potentially reused for different reasons, with
different changelog contents and dates (this last one will be a
problem with dpkg file metadata tracking). As mentioned in the above
referenced bug report, this also seems bogus (in the current context,
they were fine before), and binNMU revisions should be allocated as
unique global indexes with the same timestamp (and ideally the exact
same changelog entry (including maintainer), which would remove the
need for the changelog hacks we currently use). More so given that with
M-A:same ref-counting any binNMU that affects such package will need to
be performed for all architectures (regardless of those being affected)
to get the package in version lockstep anyway (which is also one of the
additional costs we are paying for).

While the current situation can be somewhat improved (see the binNMU
issue above), I'd hope we do not have to keep papering over that root
problem with more workarounds or additional unnecessary complexity for
something that was known to be the way it is at the time we opted into
it. :/

(In this case, I'd argue any such generated man page should be split
into their own -doc or -common or whatever package anyway.)

Thanks,
Guillem