This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author koobs
Recipients Arfrever, berker.peksag, chris.jerdonek, doko, fabiovmp, gustavotemple, koobs, lemburg, meador.inge, steve.dower, tim.golden, xdegaye, yan12125, zach.ware
Date 2016-07-27.01:14:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1469582048.01.0.994760529249.issue23085@psf.upfronthosting.co.za>
In-reply-to
Content
Forgive me for asking a question that may have already been asked, or beaten to death, but what is preventing Python from requiring libffi as an external/required dependency, rather than keeping it and taking on the burden of fixes/backporting in lieu of updates or pending releases from upstream?

Historically (at least the last ~2-3 years), libffi in Python has been plagued with, at least:

* Inconsistent / incorrect merging of libffi fixes (including regressions)
* Unsolved issues in vendored copy that have been fixed/released upstream
* Complex, manual and error-prone updates to vendored copy
* Lack of regular maintenance, from what largely appears to be a lack of knowledge about, or confidence in updating the vendored copy (fear of breakage)

I know at least FreeBSD currently requires --sytem-libffi for i386 systems in certain versions due to issue 22521 (issue 23042) and there are currently 50 open issues matching libffi (granted not all of them will be root-caused by libffi internal). I note that number to highlight the maintenance requirement.
History
Date User Action Args
2016-07-27 01:14:08koobssetrecipients: + koobs, lemburg, doko, tim.golden, Arfrever, meador.inge, chris.jerdonek, xdegaye, berker.peksag, zach.ware, steve.dower, gustavotemple, fabiovmp, yan12125
2016-07-27 01:14:08koobssetmessageid: <1469582048.01.0.994760529249.issue23085@psf.upfronthosting.co.za>
2016-07-27 01:14:07koobslinkissue23085 messages
2016-07-27 01:14:07koobscreate