an update to automake-1.11?

[Sam Varshavchik]

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.



-------------- 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/20090708/9d37ac38/attachment.sig>