- If this package can be used as a library and installs Python modules (*.so or *.py) into site-packages directories, then consider supporting installation for multiple Python versions. Please read section "Types of packages" in documentation [1] to decide if this package can support installation for multiple Python versions. - Ensure that the ebuilds do not use deprecated functions or variables. - Please check if Python 3 is supported by this package. You can temporarily set Python 3 as main active version of Python to properly test if this package supports Python 3. - If this package does not support Python 3: - Specify dependency on Python 2. You can use PYTHON_DEPEND helper variable, which should be set before inheriting of python eclass. Please read section "Specification of dependency on Python" in documentation [1]. - If this package cannot support installation for multiple versions of Python, then set active version of Python using python_set_active_version(). - Ensure that shebangs in installed scripts specify correct version of Python. If shebangs are too generic (e.g. '#!/usr/bin/python'), then you can use python_convert_shebangs() to convert shebangs. (Wrapper scripts generated by python_generate_wrapper_scripts() do not require any changes.) Please read section "Shebangs in installed scripts" in documentation [1]. - To ensure that changes applied to the ebuilds are sufficient, please temporarily set Python 3 as main active version of Python and test if this package can be properly installed and if it works at run time. Please see documentation [1] for more details. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml
If boost-1.42.0-r2 is built with USE="python" when the default interpreter is Python3 it breaks modules. e.g. with dev-python/tagpy-0.94.8: >>> import tagpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python2.7/site-packages/tagpy/__init__.py", line 24, in <module> import _tagpy ImportError: /usr/lib/libboost_python-mt-1_42.so.1.42.0: undefined symbol: PyBytes_Size adding to boost ebuild: PYTHON_DEPEND="python? 2" and to its pkg_setup(): if use python ; then python_set_active_version 2 fi worked around it for me.
I suggest to introduce "python2" and "python3" USE flags. - "python2" USE flag will be enabled by default in IUSE: IUSE="... python +python2 python3 ..." - "python2" and "python3" USE flags will be mutually exclusive. - USE="-python python2" or USE="-python python3" will disable support for Python in Boost. - Packages, which only need Boost Python headers, will depend on dev-libs/boost[python]. - Packages, which need Boost Python libraries built with support for Python 2, will depend on dev-libs/boost[python,python2]. - Packages, which need Boost Python libraries built with support for Python 3, will depend on dev-libs/boost[python,python3].
A better, long-term solution would be to convince Boost upstream to include Python version in names of Boost Python libraries (e.g. libboost_python-${Boost_version}-${Python_version}.so).
See https://bugs.gentoo.org/attachment.cgi?id=292507
(In reply to comment #4) > See https://bugs.gentoo.org/attachment.cgi?id=292507 Minor thing: is the problem with python3 and mpi still valid in the recent boost versions ? Cause if it's no longer is, such solution would be kinda broken.
Support for installation for multiple Python ABIs has been implemented in dev-libs/boost-1.48.0-r1 in Progress Overlay. I use --python-buildid option already supported by build system of Boost. Example names of libraries (symlinks without final ".1.48.0"): libboost_mpi_python-2.7-mt-1_48.so.1.48.0 libboost_mpi_python-3.2-mt-1_48.so.1.48.0 libboost_python-2.7-1_48.so.1.48.0 libboost_python-2.7-mt-1_48.so.1.48.0 libboost_python-3.2-1_48.so.1.48.0 libboost_python-3.2-mt-1_48.so.1.48.0 All Boost Python libraries are now linked against appropriate libpythonX.Y.so libraries.
Fixed in 1.48 thanks to Arfrever
This breaks anything that tries to link to libboost_python.so. A simple way to solve this is to have eselect-python add/update a symlink to the correct version-dependent name.
This breaks nothing. all the reverse dependencies are fixed. If you are using third party ebuilds please refer to the overlay maintainers. However, if you found a package that fails and is in portage tree please open a separate bug.
