Proposal for making Multi-Arch:same binNMU-safe

[Helmut Grohne]

Hi Simon,

On Thu, Apr 16, 2026 at 10:25:13AM +0200, Simon Josefsson wrote:
> In the thread, it seems the problem is that the newly built binNMU
> *.deb's have a modified time which is the same as the old ones, and that
> this is what causes problems for the backup system.
> 
> Is that a correct reading?

Yes, Ian's backup system compares a recorded modification time to the
actual modification time and backs up the file unless they match
exactly.

> If so, I wonder: what code is setting the modtime of newly built files
> to SOURCE_DATE_EPOCH?!  That seems bogus to me.  Newly built files
> should have a new modtime.  The (potentially arch-conflicting files)
> INSIDE that package should be identical to the old one, though, if the
> package supports reproducible builds.  Modulo the
> changelog.Debian.ARCH.gz file.

That is what we did for a long time. If you were to rebuild the same
package at two different points in time with the same set of
dependencies, that would get you different file modification times.
Those would be recorded in data.tar and therefore the rebuilt .deb would
differ from the earlier one. This broke reproducible builds and is what
caused the addition of SOURCE_DATE_EPOCH. Now, dh-strip-nondeterminisim
clamps the modification time of installed files to SOURCE_DATE_EPOCH and
this aspect no longer causes issues to reproducible builds.

The modification time is just one of several aspects influenced by
SOURCE_DATE_EPOCH. Some tools also use it to derive the content of
files. It is these content differences that are relevant to the M-A:same
conflicts that caused me to start this mail thread.

> I may be mis-reading the bug report, because IIRC binNMU *.deb's ought
> to have different filenames too.  If some backup system gets confused by
> two non-identical *.deb's with different filenames having the same
> modtime, that seems like a rather problematic backup system to me.
> Using different modtime's would solve that, though, it seems.

There is no obligation for a binNMU to change any filenames. Indeed, it
may even produce the very same binary packages (up to version) as
before.

Helmut