Proposal for making Multi-Arch:same binNMU-safe

[Simon Josefsson]

Helmut Grohne <helmut at subdivi.de> writes:

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

Thanks for (patiently) explaining for us lacking context!

That all sounds okay, except I don't follow why the final *.deb has to
have the SOURCE_DATE_EPOCH modtime too?

It was (and is) a good idea to clamp modtime of INSTALLED files so the
archive becomes identical.

But if a newly built *.deb file contains a modified
changelog.Debian.ARCH.gz file, it seems really strange for that *.deb
file to have a modtime value of an earlier (non-identical) package.

A better modtime for that *.deb seems to be the binNMU changelog
timestamp, for reproducability of the final archive including modtime.

What would break if you went back to setting SOURCE_DATE_EPOCH to the
last non-binNMU debian/changelog source timestamp entry AND set the
modtime of the resulting *.deb's to the timestamp of the binNMU
changelog timestamp?

/Simon

>> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260416/841d51bf/attachment.sig>