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