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/5T4UY6WO... Code of Conduct: http://python.org/psf/codeofconduct/