Steve M. Robbins wrote:
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.
Cool.
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.
Okay, agreed.
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!
I've just released Boost.CMake verson 1.41.0.cmake0, based on the
upstream 1.41.0-rc3, at
http://sodium.resophonic.com/boost-cmake/1.41.0.cmake0
Hopefully this will be easy to package, and if it isn't, I'd like to
know about it and fix it.... how can I get involved?
-t
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
