Bug#999665: dh_strip_nondeterminism breaks Multi-Arch: same in binNMUs

[Niels Thykier]

Helmut Grohne:
> Package: debhelper
> Version: 13.5.2
> Severity: important
> X-Debbugs-Cc: debian-cross at lists.debian.org, rb-general at lists.reproducible-builds.org
> 
> Hi,
> 
> [...]
> 
> The situation is that when performing a binNMU, the changelogs are
> created with differing timestamps. [...] As a consequence, the
> SOURCE_DATE_EPOCH differs. When dh_strip_nondeterminism fixes up files,
> it actually makes them differ from one another in a coinstallationset of
> Multi-Arch: same packages. Files that were previously reproducible are
> made unreproducible by dh_strip_nondeterminism.

To confirm: The root cause here is that dh_strip_nondeterminism uses the
binNMU timestamp which differs between each architecture for timestamps
*inside* the files being modified.

> The behaviour used to be
> different and the most recent non-binNMU date was considered, but that
> happend to break backup software as it could no longer detect
> modifications from a non-binNMU to binNMU upgrade. That is how we ended
> up with current situation.
> 

Clarification needed: This is about the *mtime* of files. Does this also
cover mtimes inside archives (e.g., .zip/.tar.gz) or is it only about
the mtime of the file on the file system?


As in, would it be an option for dh_strip_nondeterminism to use the
changelog date from the original upload inside the files while
debhelper/dpkg used the changelog date from the binNMU load for the
external mtimes for files?

> [...]
> 
> In order for a package to actually hit the bug, two conditions must be
> met simultaneously:
>  * Some binary package must be marked Multi-Arch: same.
>  * The build must be a binNMU.
> 
> [...]
> 
> Given that there is no progress for prolonged time, we have a choice:
> Either we produce reproducible packages that happen to not be
> installable or we produce installable packages that happen to not be
> reproducible. The trade-off appears obvious to me. Keep in mind that
> dh_strip_nondeterminism was enabled on the provision of not breaking
> stuff. Now it does break stuff.
> 

I always saw dh_strip_nondeterminism was a *temporary* solution to
kick-start the reproducibility process.  As such I hoped we would
eventually phase it out.

> As such, I propose that debhelper automatically disables
> dh_strip_nondeterminism if and only if both relevant conditions are met.
> What do you think about this?
> 

If we go that route, then the conditional would belong in
dh_strip_nondeterminism to disable itself.

> I think the reproducible builds folks favour a solution that involves
> sourcefull uploads replacing binNMUs. The proposed workaround does not
> interfere with the reproducible proposal in any way.
> 
> Do you need a patch?
> 
> Helmut
> 

For me, the options are:

 * Provided it solves the issue without regression and is feasible, we
   use asymmetric SOURCE_DATE_EPOCH timestamps inside files vs. external
   mtimes.  I am fine with providing "infrastructure" code for this in
   Dh_Lib.pm to support dh_strip_nondeterminism.

 * dh_strip_nondeterminism detects this issue itself and exits (silently
   or with a warning).

 * We phase out dh_strip_nondeterminism in the next compat level.
   - In this case, I can be persuaded to do the work around inside
     dh logic (but it would not work for "classic" debhelper and maybe
     not for overrides of dh_strip_nondeterminism).

Options that I am not interested in:

 * debhelper works around dh_strip_nondeterminism deficiencies.

Thanks,
~Niels