Proposal for making Multi-Arch:same binNMU-safe
Simon Josefsson
simon at josefsson.org
Thu Apr 16 17:28:31 BST 2026
Thanks for explaining -- I see the problem now (my backup system uses
modtime+size and could be affected by this too...), and my new
preference for solving this is to implement the 'binNMUs should be
replaced by easy "no-change-except-debian/changelog-uploads' idea from
the #894441 title, although I suspect there are objections to that.
Anything involving BinNMU's seems complex and brittle, and the entire
concept seems problematic for many reasons to me.
/Simon
tor 2026-04-16 klockan 11:08 +0200 skrev Helmut Grohne:
> Hi Simon,
>
> On Thu, Apr 16, 2026 at 11:02:33AM +0200, Simon Josefsson wrote:
> > That all sounds okay, except I don't follow why the final *.deb has
> > to
> > have the SOURCE_DATE_EPOCH modtime too?
>
> The modification time we were talking about was the one of installed
> files. I don't know whether the .deb's modification time is clamped
> nor
> am I aware of any problems around its modification time.
>
> > 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?
>
> Ian's backup system.
>
> Installed files would be changing content while not changing their
> modification time. The backup system would treat them as unchanged
> and
> skip them. His backup is inconsistent as a result.
>
> Helmut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1252 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/reproducible-builds/attachments/20260416/a7212598/attachment.sig>
More information about the Reproducible-builds
mailing list