Conrad Meyer writes:
On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote:*snip* With a subsequent release, you'll still have to rebase your existing patch, if the new release did not fix the original bug. As I understand, rpm's default settings now reject fuzz in patch files, so you'll just have to do it, now. And since the likelyhood of configure changing in a new release is no different than any other source file getting changed, on average, believing that some work can be saved just by choosing to patch a different file, then the one that really needs to be patched, is somewhat naive.The problem is that configure scripts are not written by a human, but generated by autoconf. It is easy to make small changes to configure.ac and generate large changes in configure. This makes it easier to rebase patches against configure.ac.
The macros in configure.ac generally expand out to canned shell script fragments, with the macro's parameters substituted somewhere. Changing a parameter in configure.ac usually results in an equivalent substitution in configure.
Generally, only when one adds or removes entire macros from configure.ac, that's when this results in wholesale changes to configure.
In my experience, the overwhelming majority of fixups to configure scripts involve nothing more than adjusting someone's pathname, or compiler flags. For this kind of scope, rebuilding the entire configure script is overkill, and I wouldn't do it unless I audit it and verify whether or not upstream is relying on some specific behavior in the specific version of autoconf that was used to build the original configure script. Patching the configure script is much safer than patching configure.ac, then have autoconf grok all .m4 macros and rebuild the whole thing, likely ending up with a completely different beast, that not only includes your changes but who knows what else.
Description: PGP signature