[Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main

[Daniel Kahn Gillmor]

On Fri 2015-02-13 14:33:12 -0500, Paul Gevers wrote:
> On 13-02-15 18:28, Reproducible builds folks wrote:
>> If you want to help, a first step is to check the reproducibility of
>> your packages [DDLIST]. Feel free to ask for help on the
>> <reproducible-builds at lists.alioth.debian.org> mailing list or in
>> #debian-reproducible on irc.debian.org.
>
> It would help me if you would have mentioned here what you expect people
> to do when their package is not reproducible, but when this is the
> result of other packages that they use during building. I am not going
> to fix my packages if e.g. the timestamp in the documentation is
> inserted by the use of formatXtoFormatY, we should then rather focus on
> fixing formatXtoFormatY. I believe you agree. If people all start fixing
> such issues inside their own package than in some time we have all kind
> of solutions, which may (or may not) bit-rot and may not be needed if we
> fix formatXtoFormatY.

Some of these tools have legitimate reasons in non-reproducible
environments to inject timestamps.  Even in reproducible environments,
it can be useful to inject a timestamp (a known, static one like the
value in debian/changelog) in things like generated man pages.

This means we should encourage formatXtoFormatY tools to make it easy to
expose no-timestamp and/or externally-provided-timestamp modes of
operation, and we should certainly encourage package-building frameworks
like dh to set those modes by default.  The less information we have to
encode (and maintain) in every single debian/rules or debian/control
file, the better.

However, for packages that don't use a framework we can fix, or which
use a tool that has no plans to adopt these kinds of modes upstream,
having the deviations embedded in our packaging files is the only thing
to do if we want reproducible builds.  It would be a shame if we had to
wait for every format-converter to get upgraded to do the right thing
automatically to get debian itself to a reproducible state.

Your concerns about bit-rot are legitimate, though; if a piece of the
toolchain is where a "proper" fix belongs, and all the dependent
packages are working around it now, perhaps we could (a) make sure that
the "proper fix" bug report is filed in the bts against the piece of the
toolchain, and that it is marked as "affects:" with all the packages
that are currently working around it.

If a package is doing a workaround that it shouldn't need to do, we
could even file a wishlist bug against that package and mark it as
blocked by the toolchain bug.

Basically, i think the BTS has the semantics to support keeping track of
these dependent issues so that we end up with clean long-term fixes,
while we can use our packager's discretion to implement the shorter-term
workarounds, annoying though they may be.

what do you think?

        --dkg