Re: boost migration (maybe too long message)
On Thu, Aug 02, 2007 at 01:58:21AM -0700, Steve Langasek wrote:
> 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.
it is a piece of code that works and, if used as documented by upstream,
it has not any problem at all. why should it 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.
gratuitously? the (un)reasonable Debian default was the opposite of
upstream default, which is single-threaded, and fedora and who knows
how many other distributions.
no coordination? sorry, my fault, but i am really missing the mess for
the release team, packages are waiting for boost then they are buildable.
do we want a better transition? let's call it on bts, upload boost 1.34.1
and rebuild all. let's see how better will be for the release team.
please, suggest me which version of gcc and python i should build boost
with. please consider that every time i switch gcc/python version,
boost need to sit in NEW queue for a while. only a single version of
python is supported at the same time.
> > 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.
my mail was not complete here. i am surely not willing to wait the
next boost release to fix things, so symlink playing must be applied
in the meanwhile.
regards,
domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Reply to: