Adam Jackson writes:
On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote:Richard W.M. Jones writes: > On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote:>> What line number changes? You cut a patch against configure, and you're >> done. That's it. > > And you get a big patch containing line numbers. Here's a single line> change to configure.ac, and the corresponding patch that generates: ======================Who said anything about patching configure.ac? The cited link is not a patch to the configure script, it's a result of a patch to configure.ac.I'll repeat again: patch configure, not configure.ac.I said "patch configure", and you reply, "well, it won't work because if you patch configure.ac, run autoconf, then generate the patch between the original configure, and the new configure, I get a big hairball". Duh.The fundamental problem with patching configure instead of configure.ac (or Makefile instead of Makefile.am) is that it's changing the wrong semantic level.
As was discussed previously in this thread, when creating packages the objective is not to patch the correct semantic level. If there's a problem that prevents the source from getting built properly, it's my understanding that the objective is to fix it in the way that absolutely minimizes the chance of accidentally introducing a side effect that creates a new problem that did not exist before.
Whatever you would like the upstream to do for the next release, is a separate task. It may or may not be the same thing.
So, the choices are, once it's identified where configure goes wrong are:1) Fix the configure script, with shellcode whose contents are well understood
2) Patch configure.ac, and feed it to a code generator that spits out a brand new configure script.
Your turn. Of course, if you take #2, you would, of course, verify which specific version of autoconf the upstream used, and whether the differences between your's and upstream's autoconf does not have any other impacts on the configure script.
Description: PGP signature