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