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://lists.fedoraproject.org/pipermail/devel/attachments/20090705/7055f5c4/attachment.bin 


More information about the devel mailing list