[pkg-boost-devel] Bug#553281: Bug#553281: Related bugs

[troy d. straszheim]

Leandro Lucarella wrote:
> I just did a search on closed bugs for this problem and I realized this is
> a *very* recurrent bug. Even when the Debian policy might accept the
> current dependency scheme, I think it would be best to rethink how boost
> is packaged to avoid this issues. Unfortunately the packages separation
> Debian choose is not very close on how Boost is developed and this
> artificial separation is starting to show and being a little annoying (for
> users and for maintainers, as the bogus bug reports keep coming).
> 
> I know Boost probably should be better organized in upstream to allow
> efficient packaging, but that's not how things are, and going against that
> could be very time consuming and frustrating.
> 
> I hope you can consider another way to make packages from boost that don't
> imply making the user handle the dependencies himself.

I'm a boost committer and the lead developer of Boost.CMake, an effort 
to provide an alternate method to build and package boost.  We're having 
some success, fedora and exherbo maintainers are involved and appear to 
be quite happy as we tweak the beta build for the upcoming 1.41.

As for dependencies:

The cmake build can generate a dependency tree;  it is capable of 
breaking boost up into dependency ordered modules.  It is not a pretty 
sight;  here's a picture of the dependency tree, as generated by 
'graphviz' from a cmake-generated 'dot' file:

   http://sodium.resophonic.com/boost/boost-dependencies.jpg

Build systems aside, the truth is that boost is simply not modular, 
except for a few libraries at the leaves of the dependency tree. 
Discussions on the boost-dev list about 'modularization' tailspin every 
time, as the discussion wanders to testing procedure, organization of 
boost in source control, build systems, release policies...

The only way that I could imagine breaking boost up (without playing the 
neverending game of trying to determine a dependency tree that the boost 
devs themselves do not understand) would be:

- headers
- one package per set of libs

But there is an argument to be made that until boost itself knows what 
modularity means, one should just package boost-libs and boost-headers 
and be done with it.   Boost is a monolith.  It doesn't mean you've done 
poorly if you package it that way.

I mentioned that there are fedora and exherbo guys involved in the 
boost-cmake effort.   Also there are several core cmake devs from 
kitware.  As a longtime debian user I'd be more than happy to help my 
favorite distro maintain my favorite c++ library.   More info on 
boost-cmake is available here:

   https://svn.boost.org/trac/boost/wiki/CMake

I'm on all those lists and IRC channels.  So..  if this is at all 
interesting, please get in touch.

Troy D. Straszheim