Link against the latest Boost Python version.

[jpakkane]

This fixes a Debian RC bug, so it needs to get into rc1.

[dcbaker]

@eli-schwartz you've done the most work with python dependencies, seems like something you'd want to review?

[jpakkane]

Merging this to unlock rc1. In case issues come up, those will be handled in rc2.

[dcbaker]

I am really skeptical of this patch, it means that I cannot link against an older libpython if I have multiple installed on my system, that seems like a real problem. I see the Debian bug and that's real and needs to be addressed, but this feels like it's going to cause it's own set of problems.

[dcbaker]

On Unix-like systems it seems like the correct approach here would be to use something like ldd (or manual inspection of the elf headers) to figure out what libpython it's linked against, otherwise we're just guessing.

edit: of course it doesn't link against libpython it dlopens it....

[dcbaker]

Okay, I see what's happening here.

I'd like to see the following:

• a link to the debian bug in the commit message not just int he code
• an explanation in the commit message of why we're assuming that the latest version is the one we care about

[eli-schwartz]

Gentoo definitely supports building multiple versions of Boost.Python at the same time, and installing them in parallel, and in general permits installing multiple versions of python and compiling nearly all software for any combination of python versions.

This is a critical feature to allow smooth Python transitions that happen throughout the year, where users determine when they are ready to switch and the distro simply flips a default at a certain point. Since not all software will all be ready at the same time, libraries have to support multiple versions in parallel, so that you can have one leaf program running on 3.14 while another is still stuck on 3.13 as the latest supported version.

...

I'll have to take a look at how we handle boost specifically. Or @thesamesam may beat me to it.