As far as I can tell, Gentoo is using python-buildid to install multiple versions of boost-python for our multiple Python implementations. Is this somehow a standard practice? And are we using the correct values? I guess most of the other distributions (if not all) don't support having multiple Python implementations around, so they don't care. But considering that we're explicitly applying patch to allow dots there, and I don't see any trace of such a request upstream, I'm starting to think we're diverging a bit too far. Is there any other distro out there using python-buildid? Is there a single build system supporting that thing? As far as I can tell, boost.m4 can't handle it, Paludis uses custom macros to support that and we're patching CMake to make it work.
This also causes media-libs/openimageio-1.7.13 to not find boost_python, as it uses a custom logic [1] to deduce the name of the boost_python library (in order to make boost_python support optional, while all other Boost components are required): ``` -- BOOST_ROOT -- Boost version: 1.63.0 -- Found the following Boost libraries: -- filesystem -- regex -- system -- thread -- chrono -- date_time -- atomic -- BOOST_ROOT -- Boost found 1 -- Boost version 106300 -- Boost include dirs /usr/include -- Boost library dirs /usr/lib -- Boost libraries /usr/lib/libboost_filesystem-mt.so;/usr/lib/libboost_regex-mt.so;/usr/lib/libboost_system-mt.so;/usr/lib/libboost_thread-mt.so;/usr/lib/libboost_chrono-mt.so;/usr/lib/libboost_date_time-mt.so;/usr/lib/libboost_atomic-mt.so;rt -- Boost python found OFF -- Boost python support not found -- will not build python components! ``` In the version bump to media-libs/openimageio-1.7.13 proposed in bug #596268 I fixed this by overruling OpenImageIO's custom logic and instead relying on Gentoo's patched FindBoost.cmake and FindPythonLibs.cmake. [1]: https://github.com/OpenImageIO/oiio/blob/6acdba29fc80774c39e3c7b982d8f2e20beda280/src/cmake/externalpackages.cmake#L113
Obsolete, with boost 1.70 we will 1) be using vanilla upstream Boost::Python and its buildsystem without downstream patches 2) which is fully py2/py3-multi-impl now (see commit https://github.com/boostorg/python/commit/d4d41d94aecc9f8098aabd3587fcb95458451f71) hence, this bug will be obsolete once boost 1.70 is stable and all older versions are removed.
