Re: usrmerge -- plan B?
Matthias Klumpp <mak@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: