Hi all, >> 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.
Just as a bit of throat-clearing, if you've not heard anything from the Reproducible Builds folks (or at least from me…) then the underlying reason is more that I am just not well-versed enough with the binNMU and builddd apparatus to have an informed opinion on this fairly technical and quite wide-reaching topic. In other words, it's not a lack of interest or an uncaring disregard for other parts of Debian (!), something that other mails in this thread might have accidentally implied. I'd be more than happy to change dh_strip_nondeterminism now to fix this longstanding issue for all of us, although with the proviso that the solution we want to get behind can be outlined in brief; and we seem to be close to there. > [Option:] > * We phase out dh_strip_nondeterminism in the next compat level. Not the ideal place for this info but unfortunately I don't think the rest of the archive is in a place to drop strip-nondeterminism on the next compat level. From memory, this is chiefly due to some key toolchain packages, where the required changes are not forthcoming, changes are blocking on upstream, patches have not been applied in Debian, or the discussion has stalled for various reasons. I do very much share your desire to phase out this tool completely and I even introduced a deprecation roadmap for every change that strip-nondeterminism makes for this very reason. But we're just not there... yet. > [Option:] > * debhelper works around dh_strip_nondeterminism deficiencies. Just to be explicit, I totally agree with this. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org 🍥 chris-lamb.co.uk `-