an update to automake-1.11?

Sam Varshavchik mrsam at courier-mta.com
Wed Jul 8 01:10:43 UTC 2009


Kevin Kofler writes:

> Sam Varshavchik wrote:
>> This may come as a shock to some, but configure does not often change
>> unless configure.ac changes too.
>> 
>> So, I'm not sure what does the frequency of changes to configure.ac has to
>> do with anything.
> 
> Where your argument falls apart is that patch fuzz is a local concept! It's 
> irrelevant that the file is not byte-identical. What matters is whether the 
> context lines directly above and below the line(s) you're patching changed. 
> And that's a lot more likely to happen for configure than for configure.ac.

Wrong, as usual.

Since each autoconf macro typically expands out to hundreds lines of 
shellcode, with the autoconf macro's parameter embedded somewhere in the 
middle of all that stuff, were you to change a parameter to an autoconf 
macro in configure.ac, and upstream changes the parameter in the next line, 
your patch gets broken.

If the corresponding line in configure ended up getting patched, instead, 
your patch would still apply, with fuzz, since the results of upstream's 
changes would be hundreds of shellcode lines away.

The patch would still apply.

Even if the upstream deleted the preceding, or the succeeding, macro 
altogether, your patch to configure would still apply, since it patches one 
line in the middle of several dozens of lines of shellcode, and patch(1) is 
likely to search for the necessary fuzz.

>> If someone thinks that by patching configure.ac, instead of configure, one
>> achieves tremendous savings in the frequency of needing to rebase one's
>> patches, they're in a desperate need for a reality check.
> 
> No, they're just more familiar with how patch(1) works than you.

Yes, tell me again how conflicting patches to neighboring lines in 
configure.ac "works", while the equivalent two patches hundreds of lines 
apart in configure do not.


> 
>> Furthermore, changes to configure.ac will more likely to result in a more
>> frequent manual rebases, where the corresponding changes in configure are
>> far more likely to result in much simpler rebasing that's limited only to
>> eliminating the fuzz. If one patches a line or two in configure.ac, then
>> if the upstream futzes around with a neighboring line, the patch is going
>> to get kicked out, and must be manually rebased. On the other hand, if a
>> corresponding patch was against configure, instead, (and by that I mean a
>> real patch, and not a patch to configure.ac followed by autoconf followed
>> by a diff of the new configure against the old, I hate to explicitly say
>> this, but some folks around here have a mental block on this subject, and
>> can't wrap their brains around the concept of patching configure
>> directly), the corresponding differences in configure would've ended up
>> being hundred of lines apart, resulting in nothing more than some fuzz,
>> that can be automatically updated.
> 
> Huh? It's quite the opposite, as those "hundred (sic) of lines" which are 
> inserted automatically (i.e. which do NOT come from configure.ac) are the 
> ones most likely to change,

Perhaps you should actually familiarize yourself with how most autoconf 
macros work, before you attempt to engage in a deep philosophical 
discussions on their merits.

Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, 
with the arguments to AC_PATH_PROG appearing once, in the middle of them.

Changing the parameter to AC_PATH_PROG, for example, does not change 
hundreds of lines of shellcode. This may come as a shock to you, but it does 
not.

-------------- 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/20090707/ca07dc87/attachment.bin 


More information about the devel mailing list