No subject

with previous versions of the linker, is that when the implicitly
linked library change, the application can break without knowing it,
and we (packagers) don't know that the application has to be linked
again. This is at least what we've been told in Ubuntu.
And it will be the same for Wheezy (see
http://wiki.debian.org/ToolChain/DSOLinking ): this error will become
RC and a fix has to be found (in boost or in btag).

> 3. CMake ships with a module to find the Boost modules, and that's
> what btag uses. That module could be changed to include the system
> module if the filesystem module is requested, but I'm not sure the
> CMake devs would want that. If this is "fixed" in pkg-config, I guess
> it could be "fixed" in CMake too.

In another package, I fixed the .pc file to add an implicit linked
library to the generated LDFLAGS.
Right now, I don't think this is fixed in using pkg-config, as, AFAIK,
no .pc files are delivered in the -dev packages of boost in Ubuntu
either. Until now, btag is the second package I find with this issue.

> That said, I don't want to create problems for derivatives. If the
> benefits of having this patch in Debian outweigh the maintenance
> burden of keeping track of whatever libraries the inlined methods of
> boost::filesystem rely on, please let me know and I'll try to contact
> my sponsor to get a "fixed" package uploaded.

I perfectly understand that the fix I applied in Ubuntu is not
perfect, and I think we can wait until the release of Squeeze to see
how to fix it in a clean manner: I'll merge the new packages that you
may upload in the meantime.

> By the way, I believe a better way to patch the build system would be
> adding "system" to the list of modules required in CMakeLists.txt, as
> well as adding libboost-system-dev to Build-Depends.

That's a nicer fix, yes. Anyway, I'll wait a bit to see what happen.

Thanks!

Fabrice