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.
Attachment:
pgpCGR1SP7MiB.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
