Proposal for making Multi-Arch:same binNMU-safe

[Helmut Grohne]

Hi Simon,

On Wed, Apr 15, 2026 at 04:05:27PM +0200, Simon Josefsson wrote:
> Couldn't we use the timestamp of the last source upload instead?
>
> That is, whatever code set SOURCE_DATE_EPOCH based on debian/changelog
> timestamps has to be modified.  Instead of using the timestamp of the
> most recent entry, have it skip over all binNMU entries to find the
> timestamp of the most recent non-binNMU entry.

That's an earlier solution. It was discarded, because it broke Ian's
backup system. With that scheme, a binNMU could change a file and retain
is modification time. This breaks the principle of least surprise.

> Setting SOURCE_DATE_EPOCH to the binary build date seems strange to me,
> even if you were to force it to be identical for all binNMU archs.

That's what we presently do except that it is different for each
architecture.

> This approach also solves partial binNMU: sometimes there is no point in
> scheduling a binNMU for all architectures, but only for a particular
> one.  With my approach, the SOURCE_DATE_EPOCH value will be the same for
> these partiaul binNMU's, but with your approach it will differ from the
> earlier non-binNMU SOURCE_DATE_EPOCH value.

It does not. Besides files having equal contents, the version of the
package must match exactly. Of course we could relax that, but then the
point of a binNMU is to get a different result, so we'd trade a new set
of problems arising from various binNMUs having become coinstallable
that really should not be coinstallable.

Helmut