Matthias Klumpp <m...@debian.org> writes: > (At the moment I don't actually see the upcoming doom - a few packages > broke, bugs were fixed, life goes on. If it turns out that we are not > able to cope with new bugs in time, we can always change decisions > later).
The reason why I personally jumped into this thread is that I don't think the initial fix proposed for R was good engineering. We should not be doing that sort of fragile machinations in Autoconf configuration. It will end in tears. We will miss some other binary later, or Autoconf will change flags or how it probes, and we won't catch the breakage. Doing this check in reproducible-builds definitely helps allievate my concerns as a backstop, but this is still fragile and we don't have a tight test/fix cycle. And, in general, I'm dubious of a path where we support building a package on both merged and unmerged systems and then allow running it on both merged and unmerged systems. There are so many places that binary paths creep into software build processes, and so many different upstream software build processes to analyze. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>