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! Even if upstream changes *nothing* in configure.ac, those lines *will* change whenever they use a different version of the autotools. For most upstreams, that will happen much more often than some actual change in configure.ac in the immediate context of what you're patching.
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. Chances are those context lines won't be touched for YEARS! It's just basic Statistics.
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.
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!
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 testing/unstable, Gentoo (even masked packages sometimes) etc. There are even upstream developers using Rawhide! So the version of autoconf upstream is using will change extremely often. Much more often than a 5-line window in configure.ac.
Your flawed assumption is that all upstreams are as conservative with autotools upgrades as you are.
Kevin Kofler
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.
Sam Varshavchik wrote:
You're changing the topic.
No, you're the one 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.
The original statement was: (Adam Jackson wrote:) | I suppose it depends whether you consider the initial act of package | creation, or the continued maintenance of that packaging, to be more | time consuming. All I know is that rediffing patches to configure.ac | takes way less time than rediffing against configure, and that as a | practice that hasn't (non-trivially) bitten me once in over three years, | where configure patches have.
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure.ac than for configure.
So your "if configure.ac changes" part was not in the original topic, instead it was that patches to configure.ac are less likely to be kicked out than configure when upgrading to a new upstream version.
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.
Nonsense. This was always part of the original topic, you have just been ignoring it. New upstream versions also use new autoconf versions.
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.
[snip]
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.
I don't know what upstreams you worked with. For the projects I worked on with Romain Liévin, he generally ran autoreconf with what was current on Debian unstable or testing that day and me with what was current on Fedora (stable updates) that day. The stuff would even ping-pong between the Debian and Fedora versions. And even when it was the same person regenerating it, it changed all the time. Fedora updates and Debian unstable/testing both get autotools updates much more often than once every other year. Most developers do not work on an enterprise distribution nor do they build their own autotools. They use whatever is current on their fast-moving distribution.
configure.ac itself only got minimal changes (the most frequent one was bumping the version number).
This is a bogus argument.
No, it isn't. See above. See also Ajax's statement I quoted again.
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.
What's your "typical package"? Definitely not the ones I worked on.
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.
Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations!
Kevin Kofler
On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote:
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.
Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations!
I think you both need to stop this ridiculous conversation. While I'm sure the merits of patching configure or configure.ac can and will be debated forever, you are not doing anything other than wasting each other's time.
josh
On 07/08/2009 01:44 PM, Josh Boyer wrote:
On Wed, Jul 08, 2009 at 07:17:38PM +0200, Kevin Kofler wrote:
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.
Nonsense. I'm not being intentionally dishonest, please stop those unwarranted accusations!
I think you both need to stop this ridiculous conversation. While I'm sure the merits of patching configure or configure.ac can and will be debated forever, you are not doing anything other than wasting each other's time.
I agree. Consider this an informal warning that you're both about to cross the line on "being excellent to each other".
~spot
Kevin Kofler writes:
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure.ac than for configure.
And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run.
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.
I don't know what upstreams you worked with. For the projects I worked on with Romain Liévin, he generally ran autoreconf with what was current on Debian unstable or testing that day and me with what was current on Fedora (stable updates) that day. The stuff would even ping-pong between the Debian
Well, I don't know what those projects were, but here's a better known example. I just downloaded all available versions of the 2.4 branch of openldap, and greped their configure script. The results are:
openldap-2.4.6/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.7/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.8/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.9/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.10/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.11/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.12/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.13/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.14/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.15/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.16/configure:# Generated by GNU Autoconf 2.61.
Now, let's grep configure.in:
openldap-2.4.6/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.7/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.8/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.9/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.10/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.11/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.12/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.14 2008/09/17 22:54:33 quanah Exp $ openldap-2.4.13/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.17 2008/11/21 01:26:24 quanah Exp $ openldap-2.4.14/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.15/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.16/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $
Over a span of nearly two years, openldap updated their autotools exactly once, while configure.in changed six times (with several additional intervening changes in-between consecutive releases).
Which busy project would you like to repeat this experiment with?
Sam Varshavchik wrote:
Kevin Kofler writes:
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure.ac than for configure.
And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run.
That's just because I made a mispaste. ;-)
So let's try again:
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure than for configure.ac.
(Check the actual citation if you don't believe me.)
Kevin Kofler
Kevin Kofler writes:
Sam Varshavchik wrote:
Kevin Kofler writes:
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure.ac than for configure.
And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run.
That's just because I made a mispaste. ;-)
So let's try again:
What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what "rediffing" means for us Fedora packagers), is more likely to break for configure than for configure.ac.
And I already pointed out why this is not true, several times. Furthermore, one part of your argument is that it is supposedly true because most changes to configure are due to autoconf getting updated, rather than any actual changes to configure.ac.
In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. I don't really have enough spare time to try downloading all releases, over the course of two years, of one project after another, trying to cherry-pick my example. Openldap was the first one that came to mind. I am confident that I am right, on this topic, so it was fairly likely that openldap's tarballs would've proved my point. They did, and you ignored it.
I invite you to find a counterexample, but I regret to inform you, finding one won't be easy.
Your other argument is that a patch to configure is less likely to require manual rebasing after configure changes, rather than an equivalent one to configure.ac, because new versions of autotools end up generating major changes to configure.
Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. Furthermore, as I pointed out, changes to nearby lines in configure.ac result in corresponding changes to configure being hundreds of lines apart, therefore a change to configure.ac is going to require rebasing of any patches to nearby lines, while the equivalent change to configure (once again -- for those with a short attention span -- that's a real patch to configure, and not a change to configure.ac, a regenerated configure, and a diff against the original version of configure) will therefore still apply, at most with some fuzz, and can therefore be rebased automatically.
Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update.
Case closed.
Sam Varshavchik wrote:
In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case.
That's one project. It doesn't prove any sort of a general trend.
I invite you to find a counterexample, but I regret to inform you, finding one won't be easy.
I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.).
Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf.
You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated "configure.in" file name, that says pretty much everything).
Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update.
I'm ignoring your example because it's one example against 9+ examples from me, plus Adam Jackson's packaging experiences which started this subthread. You just found the exception.
Case closed.
No, your argumentation is based on false premises.
Kevin Kofler
On 07/08/2009 08:58 PM, Kevin Kofler wrote:
Sam Varshavchik wrote:
Case closed.
No, your argumentation is based on false premises.
Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the "hall monitor"/"moderation" policies.
~spot
On Thu July 9 2009, Tom "spot" Callaway wrote:
Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the "hall monitor"/"moderation" policies.
Is the policy documented somewhere? I only found a meeting summary, which imho does not qualify as proper documentation: http://fedoraproject.org/wiki/Board/Meetings/2009-05-14
Regards Till
Hi.
On Wed, 08 Jul 2009 21:04:31 -0400, Tom "spot" Callaway wrote:
Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the "hall monitor"/"moderation" policies.
While you may argue that this discussion does not lead anywhere, and you may even be right, the tone of the discussion is definitely technical and civil in my book.
On Thu, 9 Jul 2009, Ralf Ertzinger wrote:
Hi.
On Wed, 08 Jul 2009 21:04:31 -0400, Tom "spot" Callaway wrote:
Perhaps I wasn't clear in my last post. You two need to take this offlist, or simply let this thread stop by agreeing to disagree. This is the last friendly warning I'm giving before triggering the "hall monitor"/"moderation" policies.
While you may argue that this discussion does not lead anywhere, and you may even be right, the tone of the discussion is definitely technical and civil in my book.
It was rapidly becoming less and less civil. Accusations of intellectual dishonesty and constantly repeating back and forth the same arguments are not going to keep it civil.
Additionally, it was not necessarily civil to everyone else if only b/c of the massive volume of mail it was generating that is being delivered to everyone but only involving two people.
It was time for that thread to be taken off list.
-sv
Kevin Kofler writes:
Sam Varshavchik wrote:
In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case.
That's one project. It doesn't prove any sort of a general trend.
That's one more project's worth of data that you posted yourself.
I invite you to find a counterexample, but I regret to inform you, finding one won't be easy.
I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.).
Rattling off a bunch of project names is a poor substitute for posting two years' worth of data.
Why don't you grab the last one or two years' worth of these projects' releases, and see how many releases had updated configure.ac scripts, and how many releases were rebased to newer versions of autoconf.
You know, like what I did, for openldap.
But, I'm pretty sure I know what you'll expect to find. And you know the same thing, too. And which is why you don't want to do it.
Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf.
You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated "configure.in" file name, that says pretty much everything).
No, it means that there is absolutely no reason to rename a file, just for the heck of it. Whether it's configure.in or configure.ac, it's irrelevant. Or, perhaps, you'd like to explain the major difference between naming the source file for autoconf as configure.in, or configure.ac.
And I didn't really do much of finding, as I said. It's one of the packages that I'm tracking on http://manpages.courier-mta.org which has the largest archive of historical releases. But, you're demanding to look at some project that uses configure.ac?
Sure. Not that it makes one fig's worth of difference, of course, whether it's configure.in or configure.ac, but here you go: pcre. It's another one that I'm tracking. Upstream only has the last four releases available, but they also span about a year and a half chronologically, rougly the same time span as openldap:
pcre-7.6/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.6. pcre-7.7/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.7. pcre-7.8/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.8. pcre-7.9/configure:# Generated by GNU Autoconf 2.63 for PCRE 7.9.
Looking at pcre's configure.acs, only pcre-7.8 had no substantive changes from the previous version, all the others contained very major changes. Looks like this one doesn't agree with your theory, too.
So go ahead, and tell me again how that's still insufficient data for your liking (all the while offering zilch of hard data yourself, I note). I'll be happy to continue, as long as you like, but, you must understand, the hits will just keep on comin'.
I also snuck a peek at the evolution of GnuTLS's toolchain. I guessed that it would be your best hope of salvaging some crumb of hard data that goes your way -- given that it's a GNU project and thus would be the most likely ones to always rebase to the latest-and-greatest autotools.
Well, I looked at it, and would you like to see how GnuTLS's version history actually is? I'll be happy to post it. All you have to do is ask.
Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update.
I'm ignoring your example because it's one example against 9+ examples from me,
You did not post a single example. Rattling off names of packages is not the same thing as actually listing which version of autoconf generated each version, and how many original changes went into the corresponding configure.in (or configure.ac), thus giving you an actual look at what the rate of change is to configure.ac, versus the rate of change to the version of autotools that generated the configure script. Why don't you do that, and really prove how wrong I am?
Take 5, take note of Spot's msg.
Regards,
Frank