Re: [boost] [pkg-boost-devel] Boost.Python: Build and Install with Python 2.4 and 2.5?
Hi, Thanks to Steve, Bernd, and Josselin for ideas. On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another?
That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested.
Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
Hi,
Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
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
I think this is fine.
[ ... ]
The solution is to keep the names decorated with both python versions, but to maintain a farm of symbolic links pointing to the current python version. As Steve noted, you don???t need one for the runtime libs, but for the .a and the .so symlink that are used at build time, this is required.
OK, both you and Bernd suggested rtupdate. Bernd even pointed me to a description of it [1]; thanks. Let me see if I understand your proposal. The idea is to create a single -dev package that contains the following in /usr/lib: libboost_python-py24-gcc42-1_34_1.so libboost_python-py24-gcc42-1_34_1.a libboost_python-py25-gcc42-1_34_1.so libboost_python-py25-gcc42-1_34_1.a The -dev package contains an rtupdate script to create the following symlinks (also in /usr/lib): libboost_python-gcc42-1_34_1.so libboost_python-gcc42-1_34_1.a Does that sound right? This has the advantage that a Python extension can be build and packaged for either or both supported Python versions, albeit at the cost of changing the link line. Code that just needs the default version can use the undecorated form in the link line. The disadvantage is that if you use the undecorated form, you're not quite sure what version of Boost.Python is linked in. -Steve [1] http://people.debian.org/~srivasta/manoj-policy/x673.html
Steve M. Robbins wrote:
Hi,
Thanks to Steve, Bernd, and Josselin for ideas.
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another?
That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested.
Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem.
extensions for different python installations don't conflict because they end up in separate directories. Python's own runtime library does a similar thing: it is installed in <prefix>/lib/python<version>/config. What if boost.python gets installed into that directory, too ? Wouldn't this solve the issue ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
Steve M. Robbins wrote:
Hi,
Thanks to Steve, Bernd, and Josselin for ideas.
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another?
That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested.
Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem.
extensions for different python installations don't conflict because they end up in separate directories.
The proposal above is that we provide a boost-python-2.4-dev and a boost-python-2.5-dev package that conflict with one another (because they would contain files of the same name). This prevents a source package from depending on both for a build, and therefore a source package for a Python extension cannot produce an extension for each Python version. -Steve
Steve M. Robbins wrote:
On Tue, Feb 26, 2008 at 11:15:24PM -0500, Stefan Seefeld wrote:
Hi,
Thanks to Steve, Bernd, and Josselin for ideas.
On Sat, Feb 23, 2008 at 09:17:24PM -0800, Steve Langasek wrote:
Decorate only the shared library names with the python versions, and retain the current names for the .a files and .so symlinks - with two separate -dev packages that conflict with one another?
That still prevents anyone from packaging an extension that builds for both python2.4 and python2.5 at once using Boost.Python, but I think it solves all the other drawbacks of the other solutions you suggested. Indeed. Do you think this is a serious restriction? Given that Debian likes to package extensions for all python versions, I tend to think it will become a problem. extensions for different python installations don't conflict because
Steve M. Robbins wrote: they end up in separate directories.
The proposal above is that we provide a boost-python-2.4-dev and a boost-python-2.5-dev package that conflict with one another (because they would contain files of the same name). This prevents a source package from depending on both for a build, and therefore a source package for a Python extension cannot produce an extension for each Python version.
How does this work for source packages using Python-dev directly ? Don't they face the same problem ? (I still don't see the problem: Source packages don't depend on binary packages, only binary packages do. And if you package your extension module you are in control of what python version(s) you build against, no ?) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Wed, Feb 27, 2008 at 08:43:43AM -0500, Stefan Seefeld wrote:
(I still don't see the problem: Source packages don't depend on binary packages, only binary packages do.
Source packages *do*, in fact, depend on binary packages. Each source package describes exactly the packages required to build the source; e.g. whether Qt3 libraries or X11 libraries are needed. These are called "build-time dependencies" or "build-deps" for short.
And if you package your extension module you are in control of what python version(s) you build against, no ?)
That's a true statement. Several extension modules will, in fact, build for both Python 2.4 and 2.5. Now imagine an extension module that uses Boost.Python. As mentioned, it must have the relevant build-deps. To support this, the relevant boost-python development packages must be co-installable (i.e. not conflict with each other). It's not yet clear to me whether this is an achievable goal, but it would be nice. Regards, -Steve
Hi, On Tue, Feb 26, 2008 at 10:04:26PM -0600, Steve M. Robbins wrote:
On Mon, Feb 25, 2008 at 01:15:31PM +0100, Josselin Mouette wrote:
The solution is to keep the names decorated with both python versions, but to maintain a farm of symbolic links pointing to the current python version. As Steve noted, you don???t need one for the runtime libs, but for the .a and the .so symlink that are used at build time, this is required.
OK, both you and Bernd suggested rtupdate. Bernd even pointed me to a description of it [1]; thanks. Let me see if I understand your proposal.
The idea is to create a single -dev package that contains the following in /usr/lib:
libboost_python-py24-gcc42-1_34_1.so libboost_python-py24-gcc42-1_34_1.a
libboost_python-py25-gcc42-1_34_1.so libboost_python-py25-gcc42-1_34_1.a
The -dev package contains an rtupdate script to create the following symlinks (also in /usr/lib):
libboost_python-gcc42-1_34_1.so libboost_python-gcc42-1_34_1.a
Does that sound right?
It may sound even better if multiple Boost versions were considered, packaging them in versioned source packages (ie boost-1.34.1, boost-1.35.0). Respective -dev packages should then be also versioned and conflicting each other, as the mostly undecorated symlinks there provided. Having boost-defaults driving the default Boost and Python versions and the completely undecorated symlinks. This, for instance, would allow Boost 1.35.0 in lenny while 1.34.1 being the default one. I frankly doubt a full transition to 1.35.0 would happen before the release of lenny. Ciao, Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
participants (3)
-
Domenico Andreoli -
Stefan Seefeld -
Steve M. Robbins