Hi, I'm part of the Debian Boost packaging team, seeking some guidance on how to build and install Boost.Python so that it is usable with all Python versions shipped in Debian. Debian currently ships Python 2.4 and 2.5. When reading the following, keep in mind that Boost.Python is not a Python extension but, rather, a library that eases writing an extension in C++. So it is necessary that the compiled libraries be visible to be linked with user-written C++ code. One idea is to use a user-config.jam file containing using python : 2.4 : /usr ; using python : 2.5 : /usr ; Then run jam twice bjam variant= ... bjam variant= ... python python=2.5 This produces pairs of library files such as bin.v2/.../link-static/libboost_python-gcc42-1_34_1.a bin.v2/.../link-static/python-2.5/libboost_python-gcc42-1_34_1.a (and similar pairs for shared libraries and all other variants). The key item to note is that the two files have the same name. The python version, unlike the GCC version, is not embedded in the library name. So these files cannot both be installed into /usr/lib. The question, then, is how to distinguish them once installed? Should we: 1. Rename the resulting libraries to decorate them with the python version in addition to the gcc version? This could generate libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.a 2. Similar to above, but use bjam's --buildid option? This has the drawback that the build ID shows up differently than the GCC version decoration, e.g. libboost_python-gcc42-1_34_1-py24.a libboost_python-gcc42-1_34_1-py25.a 3. Put the libraries in different subdirectories, e.g. /usr/lib/python2.4/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a 4. Put the default version directly in /usr/lib and the others in subdirectories, e.g. /usr/lib/libboost_python-gcc42-1_34_1.a /usr/lib/python2.5/libboost_python-gcc42-1_34_1.a The drawback to all these approaches is that client code has to be adjusted to build on Debian. Linking against Boost (for non-bjam projects) is already hard enough with the decorated library names that I fear making the situation worse. The attraction of #4 is that at least the variants for the default python version are found in a natural manner. This has some appeal to me, personally, but I worry that it is too easy to build an extension to python 2.5 and link in the wrong Boost.Python library. In contrast, the other options have the advantage that it forces the user to declare which version of Python is being used. I'd appreciate your thoughts. Have I overlooked a better solution? What are the other packagers of Boost.Python doing? In principle, it would be nice to have the Boost libraries named the same across distributions. Thanks, -Steve