Hi, although Boost has some packaging issues which are blocking its migration to testing, along with other 27 packages, I believe it should migrate anyway.
Let me describe current issues. First blocking issue is an unfortunate mess in library naming. Upstream build system provides two ways to name libraries, while one is not suitable for linux distributions (no version in the soname) the other is at least difficult to manage in a portable way (fully decorated sonames encoding compiler, library version, multi-thread ability, etc). I tried to simplify the management of these complicated sonames until 1.34.0, when I definitively realized it was a pretty bad idea. I then started/tried to recover but many Debian packagers were surprised (I did not correctly warned them) and many rdepends started to FTBFS. Current status is not definitive and surely not satisfying but Boost is far from being unusable and surely should not be blocked because of this (RC bug #429533). Second issue is about the python version used to build Boost.Python, which I chose to be 2.5, trying to anticipate transition of default python to 2.5. This transition is planned but not yet started, so I was pretty optimist and too ahead respect the times. This does not help the integration of Boost based Python extensions with other python packages but the only reported problem is with tagpy (RC bug #426871) and its rdepend sonata. IMHO, these could go with Python 2.5 and be happy with current Boost.Python. Again, I do not think Boost should stay in unstable because of this. Let me now talk about how bad would be forcing the solution of these issues before letting Boost migrate to testing. In order to really fix first issue, discussion with upstream developers should be ultimated and should converge to a solution. Such a solution would not appear before next stable release (1.35.0). Time here is measured in months, given that latest stable (1.34.1) has been released few days ago. Palliative solution is playing with symlinks, maybe restoring the old ones, which again reduces everything to a Debian-specific game. This may be applied immediately but IMHO would only throw the problem a little forward on the way. Surprisingly many developers seem to prefer this short-looking solution. I prefer to temporary keep current crystal-clear Debian-specific hacks while still providing, as always, the upstream difficult to use portable way to link with Boost libraries. Talking about second issue, rebuilding Boost with python 2.4 would require a change in the package name of Boost.Python, a journey in the NEW queue, falling in the archive in a random time with the risk of melting some new library transition that might be started in the meanwhile. And maybe just avoid the migration of default python to 2.5 for a matter of few weeks. I do not really care if Boost 1.34.0 enters testing right now, indeed I have 1.34.1 sitting in experimental which is built with gcc 4.2 and python 2.5. As soon as transition to gcc 4.2 starts, I will upload it to unstable. I only think it might be the case of letting some packages enter testing now, while the situation is still not satisfying but neither that bad. I am surely available to apply any modification the RMs would require in order to ease the migration. Best regards, Domenico Andreoli -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
signature.asc
Description: Digital signature
