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
signature.asc
Description: Digital signature
