[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: boost migration (maybe too long message)



On Mon, Jul 30, 2007 at 01:01:39AM +0200, Domenico Andreoli wrote:
>   although Boost has some packaging issues which are blocking its
> migration to testing, along with other 27 packages, I believe it should
> migrate anyway.

No, it should not.

> 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).

Yes, it most definitely should be blocked.

Libraries are included in Debian so that they can be used by applications
that require them (either packaged or local apps), not for their own sake.
You've made a change to the packaging of boost libraries that *gratuitously*
breaks most of the reverse-dependencies in Debian, with apparently no
coordination with the maintainers of those reverse-deps -- this is your mess
to clean up, the release team isn't going to take it out on the maintainers
of application packages by rendering them uninstallable and unbuildable in
testing.

> 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 don't see why this should be short term at all.  Expecting application
developers to have to explicitly choose between multithreaded and
single-threaded libraries, instead of providing a reasonable default,
doesn't make any sense; boost is the only library I know doing this today.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/



Reply to: