an update to automake-1.11?
Sam Varshavchik
mrsam at courier-mta.com
Sun Jul 5 14:45:46 UTC 2009
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090705/7055f5c4/attachment.sig>
More information about the fedora-devel-list
mailing list