Message271425
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. |
|
Date |
User |
Action |
Args |
2016-07-27 01:14:08 | koobs | set | recipients:
+ 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:08 | koobs | set | messageid: <1469582048.01.0.994760529249.issue23085@psf.upfronthosting.co.za> |
2016-07-27 01:14:07 | koobs | link | issue23085 messages |
2016-07-27 01:14:07 | koobs | create | |
|