Kevin Kofler writes:
Sam Varshavchik wrote:Wrong, as usual.That's an ad hominem "argument".Since each autoconf macro typically expands out to hundreds lines of shellcode,But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or aclocal version!
You're changing the topic.On this point, we're not talking about what happens when autoconf changes. Here, the original statement was that patches to configure.ac are less likely to be kicked out than configure, if configure.ac changes.
I pointed out that this is completely absurd, and you have no idea how autoconf works. You have no answer, so you must now start talking about what happens when autoconf itself changes.
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.Upstream is much less likely to change that parameter in the next line than to use a different version of autoconf.
Do you have any data to back up this interesting notion -- that most changes to configure are due to autoconf version changes, rather than upstream making changes to configure.ac itself?
I thought not.
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.You don't understand me, I'm telling you how patches to configure.ac in an area upstream is unlikely to touch any time soon work, while the equivalent patches in configure get fuzzed by unrelated changes introduced by a new autoconf used by upstream and break.
This is absurd. configure.ac changes due to natural evolution of the package far more often than autoconf itself changing.
In fact, many actually loathe switching to a different version of autoconf, preferring to stay on the same version as long as possible.
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.But those "several dozens lines of canned shellcode" CHANGE WITH THE AUTOCONF VERSION!
Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year.
This is a bogus argument.
Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode.No, but using the next point release of autoconf, even with no changes to configure.ac at all, does.Most programmers use fast-moving distros. Distros like Fedora, Debian
It would be trivial to pick a typical package, and look at intervening releases, years apart, and observe the major differences in configure.ac, yet, perhaps only one, if none, update to autoconf itself occuring in all the intervening releases.
But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes.
Attachment:
pgpRXKWx43OP3.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
