<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <div class="moz-cite-prefix">On 3/4/24 22:25, David A. Wheeler via
      rb-general wrote:<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:222BFDA7-BB1B-480B-B3A4-98C3F462BB0D@dwheeler.com">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On Mar 4, 2024, at 3:37 PM, Holger Levsen <a class="moz-txt-link-rfc2396E" href="mailto:holger@layer-acht.org"><holger@layer-acht.org></a> wrote:

On Mon, Mar 04, 2024 at 11:52:07AM -0800, John Gilmore wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">Why would these become "wishlist" bugs as opposed to actual reproducibility bugs
that deserve fixing, just because one server at Debian no longer invokes this
bug because it always uses the same build directory?
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
because it's "not one server at Debian" but what many ecosystems do: build in an
deterministic path (eg /$pkg/$version or whatever) or record the path as part
of the build environment, to have it deterministic as well.

in the distant past, before namespacing become popular, using a random path
was a solution to allow parallel builds of the same software & version.

and yes, this is a shortcut and a tradeoff, similar to demanding to build 
in a certain locale. also it makes reproducibilty from around 80-85% of all 
packages to >95%, IOW with this shortcut we can have meaningful reproducibility
*many years* sooner, than without.

and I'd really rather like to see Debian 100% reproducible in 2030, than in 2038.
and some subsets today, or much sooner.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I agree with Holger (and Vagrant).

It'd be *nice* if a build was reproducible regardless of the directory used to build it.
But today, if you're building an executable for others, it's common to build using a
container/chroot or similar that makes it easy to implement "must compile with these paths",
while *fixing* this is often a lot of work.

I suggest focusing on ensuring everyone knows what the executable files contain, first.
if people can add more flexibility to their build process, all the better, but that added flexibility
comes at a cost of time and effort that is NOT as important.

--- David A. Wheeler

</pre>
    </blockquote>
    <br>
    Yet another +1 "here, here!" to this.<br>
    <br>
    Flexibility is desirable.  Determinism even without maximal
    flexibility should still get the main thrust, and it is _not_
    sufficiently solved yet in many situations and many pieces of
    software.<br>
  </body>
</html>