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

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [Reproducible-builds] Reproducible Builds — proof of concept successful for 83% of all sources in main"):
> 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,

I think that if tool upstreams reject (or stall) our requests for
reproducible-compatible modes of operation, we should apply such
patches ourselves.

But I hope this will be very rare.

Certainly we should be willing to backport patches from upstreams'
development versions to testing (when testing isn't frozen).

> 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.

I would generally very much prefer to fix things at the root.  That is
less effort overall.  It may mean that this specific goal is achieved
less quickly, but if we spend less effort achieving this goal we can
spend that effort on other goals that are also important.

We ought to be able in any case to get very far within a single Debian
release cycle.

> 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?

Also, less involvement with annoying workarounds means less annoyance
and therefore more fun and therefore more work and faster progress.


This does depend of course on the interactions between different
maintainers on these subjects also being fun and constructive.  If
they aren't then a workaround may be better.

(IMO such maintainers ought to be replaced.  We have too many who are
hard to work with.  But the only sensible way to get rid of them, or
even just to get a needed patch accepted, is to ask the Technical
Committee; and the TC has shown itself to be extremely reluctant to
intervene.)

Ian.