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

[Steve M. Robbins]

First of all: thank you, Leandro and Troy, for your interest in Boost
and enthusiasm at improving the Debian packaging of Boost.

On Mon, Nov 02, 2009 at 09:57:50PM -0500, troy d. straszheim wrote:
> 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).

You are right that this is a recurring problem.  Indeed, it seems to
me that the problem is becoming worse.  This might be due to Boost
getting larger and more interconnected (causing more such "bugs") or
maybe Boost is just getting more popular (cause more *reporting* of
such "bugs") or maybe my memory is just playing tricks on me :-)

Whatever the reason, I am persuaded now that the best course of
action is to stop splitting up the headers.  The next upload
of boost1.40-dev will have all headers.


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

Yikes!  


> 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

Agreed.  That's what the next Debian upload will be.


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

True.  However, in the context of Debian I believe that there is value
in keeping the run-time libs in separate packages.  That way,
installing a package that uses only Boost.Regex will pull in only
libboost-regex1.40.0 and not the 15 other libraries.  A
not-insignificant fraction of Debian users do care about limiting
"package bloat".

For the same reason, I chose to retain the separate -dev packages: a
user that only wants to *build* against Boost.Regex can install
libboost-regexp-dev and not pull in 15 other libraries.


> As a longtime debian user I'd be more than happy to help
> my favorite distro maintain my favorite c++ library.

We are more than happy to have help.  Right now the "Debian Boost
Team" contains two people, only one of whom is active at any given
time.  More blood is welcome!

Best regards,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20091114/1959d94d/attachment.pgp>