[pkg-boost-devel] Question about multiple boost packaging

[Deng Xiyue]

On Sat, Aug 16, 2008 at 04:19:59PM -0500, Steve M. Robbins wrote:
> We haven't discussed any concrete plan to remove old versions.
> However, Debian already has 2 versions of Boost and I'm currently
> packaging the newly-released 1.36.0.  That will make three versions,
> which is probably 1 too many.
> 

Now that 1.37.0 is almost out-of-door, and that means there's going to
be 4 versions of Boost in parallel based on the current packaging
scheme, which is IMHO mirroring the chaos of berkeley db.  A proper
method of dropping older releases is needed.

I've thought of one that may be quite preliminary:

1. Make existing boost<version> packages installs development headers
into versioned include directories like ``/usr/include/boost_1_36_0'',
and stop shipping unversioned symlinks to libs in them.

2. As the previous mails suggest, provide a free-standing boost
packages that consists of unversioned -dev packages like
libboost-foo-dev that depends on the ``default'' version of
libboost-foo<version>-dev - while which version is default is to be
determined - and provide a symlink to the corresponding default
version's development header, like ``boost -> boost_1_36_0/boost'',
and unversioned symlinks to the libs in /usr/lib, like
``/usr/lib/libboost_regex.so -> libboost_regex.so.1.35.0''

3. Suggest rdepends depending on this default boost package to avoid
changing of header place and linking.

That may help rdepends to migrate to newer boost releases by binNMU,
but still leaves some problem to be solved.  One of them is what to do
when a rdepend cannot be trivially ported to newer boost releases?  In
such case one have to manually add
``-L/usr/include/boost_<older_version>'' to LDFLAGS, and have to
``-lboost_<component>-<compiler>-<version>'', which is not elegant,
but still applicable.  Another might be: who will do the migration
test.

Thoughts?

Regards,
Deng Xiyue