Richard W.M. Jones writes:
There's been lots of previous discussion of this silly idea of
patching generated code. You end up carrying enormous patches
containing just line number changes that often can't be applied
upstream, and can't be carried forward to new upstream releases --
What line number changes? You cut a patch against configure, and you're
done. That's it.
When a later release rolls down the pike, the patch gets rebased, and fixed
up, against a newer version.
I fail to see any substantive difference between that, and patching any
other file in the source tarball. 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.
what on earth use is that? And still no one has explained
coherently
why the sky will fall if we patch configure.ac and Makefile.am and
just rerun autoconf/automake in the specfile.
Because autoconf and automake are going to change a lot more than just what
the patch was intended to patch. It's fairly likely that the upstream is
using a different version of autoconf and automake, so this ends up
producing a brand new configure and makefile. If I were to do that, then
I would find it necessary to spend additional time testing the new configure
script, running it an eyeballing all of its voluminous output, watching for
something that falls out, as a result of the new configure script.
Dunno, it just seems much easier to me to just patch a single line in
configure, adding or fixing some directory's name, then to do all that. I
get the impression that there's a meme going around that patching configure
is some kind of a herculean, impossible task, and that's its easier to patch
configure.in, then run autoconf to generate a brand new configure script.
I suppose that there may be some situations where rebuilding the configure
script is the right thing to do, but I wouldn't expect to have this happen
very often.