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.
Attachment:
pgpdLdc1FPbWG.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
