The boost_python libraries are built against each version of python. When changing between versions of python, the dynamically linked version of libboost_python-*.so should also be updated. Many programs link against -lboost_python, so managing a lint from /usr/lib/libboost_python.so -> /usr/lib/libboost_python-?.?.so would be helpful. # type python python is /usr/bin/python # eix eselect-python [I] app-admin/eselect-python Available versions: ~20090804[1] 20091230 20100321 20111108 (~)20131210 **99999999 Installed versions: 20131210(05:55:10 AM 01/19/2014) # eix -e python [I] dev-lang/python Available versions: (2.6) 2.6.8-r3 ~2.6.9 (2.7) 2.7.5-r3 ~2.7.5-r4 ~2.7.6 (3.2) 3.2.5-r3 (3.3) 3.3.2-r2 (~)3.3.3 # find /usr/lib/ -name \*boost_python\*.so /usr/lib/libboost_python-3.3-mt.so /usr/lib/libboost_python-2.6.so /usr/lib/libboost_python-2.7.so /usr/lib/libboost_python-2.7-mt.so /usr/lib/libboost_python-3.2-mt.so /usr/lib/libboost_python-3.2.so /usr/lib/libboost_python-3.3.so /usr/lib/libboost_python-2.6-mt.so Thanks and best regards, EBo --
That would would make it really easy for an ebuild developer to be lazy and let a package link with the active version of libboost_python, when they should probably be using the python-r1 or python-single-r1 eclass. I'm not against being lazy, but I wonder what kind of weird problems that might cause. In any case I think this probably belongs in a separate eselect module. I don't think there is any reason to tie the active libboost_python to the active python interpreter.
Not to mention that for ebuild use the eclass should manage it and not eselect-python.
Should we close this bug then?
Yes, I guess so, since we seem to silently agree on not pursuing the problem further.
I agree. I figured that the bug is nearly 3 years old and we had found a work around for it... Actually I completely forgot about this bug report until I posted another bug today. Thought it would be good to close it.
