On Tue, Aug 25, 2015 at 07:08:06PM +0100, Ian Jackson wrote: > Not regenerating configure doesn't pose any significant risk that > we're shipping a configure script that we can't regenerate (or, at > least, regenerate an equivalent or better one). I've not heard of > people (for example) using private autoconf macros not included in > their build tree.
Even though this has been disputed by Jakub Wilk already, let me give another example: The configure script included with src:blt cannot be regenerated anymore. Bug #772590 contains my attempts to fix that. From my pov src:blt FTBFS. This is also not the first time where a configure was buggy and regenerating it would have solved the problem, but regenerating is no longer possible. The worst example I ever saw is nothing less than Perl's Configure. In bug #762638, we agreed that Perl's Configure shell script, which is generated by metaconfig, is considered preferred form for modification and thus does not need source code included. But the irony goes on. When I sent a patch against Configure, it was rejected, because what I wanted should be done in metaconfig[1], i.e. Perl upstream implicitly acknowledged that it is not preferred form for modification. The Debian Perl maintainers have been very helpful in trying to address this situation, but without more help from upstream, they cannot fix it. What all of this shows however is that not regenerating configure scripts during build has a significant risk of causing severe maintenance problems down the road. When this reaches the point where the generated scripts is called source, sanity is lost. Please, let's always build from source. Let's not just apply this to JavaScript libraries. The only way to provide the freedom to build from source is to regularly do it. Helmut [1] https://rt.perl.org/Public/Bug/Display.html?id=124326#txn-1351869
