Proposal for making Multi-Arch:same binNMU-safe
Simon Josefsson
simon at josefsson.org
Thu Apr 16 09:25:13 BST 2026
Jochen Sprickerhof <jspricke at debian.org> writes:
> Hi Wookey,
>
> * Wookey <wookey at wookware.org> [2026-04-15 19:59]:
>>Which Ian are we talking about here (or is there a backup package in
>> debian called 'Ian's backup system')?
>>Does this issue affect more people than 'Ian'?
>>
>>Why does it break when binNMUs are built to (internally) match the
>> SOURCE_DATE_EPOCH?
>>
>>Should a backup system not be able to cope with new files that have
>>old dates in them (are the timestamps of the debs themselves set to
>>the SOURCE_DATE_EPOCH?)
>>
>>Essentially I am wondering if perhaps this backup system should be
>>fixed, rather than the build systems changed?
>>
>>Perhaps this has all been discussed already somewhere, and there is a
>>good reason why this option has not been included in the solution-set?
>>If so, do you have a pointer?
>
> See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773
The problem isn't entirely well analyzed or summarized there, I think.
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?
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.
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.
/Simon
-------------- 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/b9c3304f/attachment.sig>
More information about the Reproducible-builds
mailing list