Package: debhelper Version: 13.5.2 Severity: important X-Debbugs-Cc: debian-cr...@lists.debian.org, rb-gene...@lists.reproducible-builds.org
Hi, dh_strip_nondeterminism was automatically enabled on the provision that it wouldn't break stuff. To a large extend, that's the case. Unfortunately, there is a corner case where it does get things wrong and we cannot make progress as the requirements appear to conflict with one another. The issue is reported as #950806. The situation is that when performing a binNMU, the changelogs are created with differing timestamps. (That's a technical limitation of our archive implementation. In theory, binNMUs could use equal timestamps and sbuid already has --binNMU-timestamp.) 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. 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. So we're actually talking about a relatively small set of affected packages. Unfortunately, libruby2.N is among them and that has a relatively high impact. But the issue does not stop there. We've had other high profile cases in the past. They tend to pop up at unfortunate times. 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. We can estimate this set using grep-dctrl: grep-dctrl '(' -r -F Version '.*+b[0-9]\+$' ')' --and '(' -F Multi-Arch -X same ')' -s Package -n $PKGFILE For unstable, that's about 2100 binary packages built from 900 source packages at present. 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. 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? 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