I personally think we shouldn't worry about it. I try to use an autoconf version at least as recent as what was used for the current file, but beyond that it is unlikely anything depends on autoconf distroisms within our own in tree configure.

Forcing humans to do weird tricks (always guaranteed to fail) to keep this in some I'll defined state or another seems odd given anyone can rerun autoconf (as the F package apparently does?) themselves if an issue with it ever comes up. We only check it in and ship it in source tarballs as a convenience.

--
blame half the typos on my phone.

On Sun, Dec 15, 2019, 5:33 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
On Sun, 8 Dec 2019 at 23:58, Nick Coghlan <ncoghlan@gmail.com> wrote:
> Does anyone have any recommendations for dealing with this? My current
> plan is to revert back to the configure script from master, run
> autoreconf, and then use `git add -p` to only add in the desired
> changes, leaving everything else as it was on master.

I didn't end up using this plan. Instead, I copied the configure
script *output* from master, and then used "git add -p" to revert the
changes that arose solely from running autoreconf on a non-Debian
system, while keeping the intentional changes from the PR.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5T4UY6WON6ZTLAG36ELAYX4K6UDTVXGE/
Code of Conduct: http://python.org/psf/codeofconduct/