[pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released

[Steve M. Robbins]

On Sat, Apr 19, 2008 at 03:43:35PM -0500, Steve M. Robbins wrote:
> On Fri, Apr 18, 2008 at 12:20:39PM +0200, Domenico Andreoli wrote:
> 
> > I think new and separate boost-1.35 package is the best option we have:
> > 
> >  1. It may be uploaded now and released with lenny without touching
> >     any reverse dependency
> >  2. Never more huge transitions, reverse dependencies take 1.35 as
> >     they like
> 
> I think we might as well support multiple boost versions.  As you
> point out, there is a big advantage in not forcing a transition each
> time Boost releases.
> 
> The remaining question is whether we support co-installation of
> multiple -dev packages.  The fact that Boost upstream *does* support
> this -- by embedding the boost version into both the link library and
> the include directory names -- makes me lean towards this option.

... but now that I've thought a little harder, I've realized it
brings several negatives:

* The simplified link library names (i.e. -lboost_wave rather than
  -lboost_wave-gcc42-1_35) are difficult to manage.  I can think of
  a couple of poor options: drop them completely; or use alternatives.

* Ditto for the simplified include directory structure: /usr/include/boost
  rather than /usr/include/boost-1_35/boost.

* The tools "bcp" and "pyste" suffer from a similar problem: they
  are currently installed into /usr/bin.  For these tools to coexist
  in 1.34.1 and 1.35.0 versions, they'd need a suffix added, or the
  like.


In contrast, the alternative strategy of having all the libfoo-dev
(1.34.1) packages conflict with libfoo1.35.0-dev packages has just a
single negative: that you can't develop simultaneously with 1.34.1 and
1.35.0.  On the positive side, however, you can install the 1.35 -devs
and the existing build scripts will work because the include path and
the simplified link library names are preserved.


So unless anyone (Domenico?) has a strong preference for the
first option, I'm planning to pursue the second.

Thanks,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20080429/d3d241ac/attachment.pgp