Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Mon, May 05, 2008 at 06:16:04PM +0200, Domenico Andreoli wrote: On Sat, May 03, 2008 at 12:15:39AM -0500, Steve M. Robbins wrote: My headache now is that there are 13 -dev packages in Boost. One (libboost1.35-dev) contains 60+ header-only libraries, while the others each contain 1 library that happens to build a shared object. This overhead creates a nonnegligible amount of complexity and generates bugs (e.g. #457654, #478782). Is there any value to this granularity? I can't see any. If there are no objections, I'm leaning towards collapsing all the -dev packages into libboost1.35-dev -- and rolling bcp into it, as well. I'll probably keep libboost-python1.35-dev separate (with pyste rolled into it). Your thoughts? please, proceed. I'm making progress :-) However, the long build times makes fixing the packaging errors quite drawn out. So far I have rolled bcp into libboost1.35-dev and pyste into libboost-python1.35-dev. Then I realized the following. Each Boost component that builds a shared library has both a libfoo1.35.0 and a libfoo1.35-dev package. If I roll up the -dev packages into libboost1.35-dev, then it will ship with dangling link name symlinks (libfoo.so) unless I also roll up all the shared libs into liboost1.35.0. I don't think the former (dangling links) will pass muster; so if we collapse the -dev packages, we must also collapse the shared library packages. I see some value in the granularity of having each shared lib live on its own: a system that needs only Boost.Regexp doesn't have to pay the disk space for also having Boost.Python. But maybe it's not so important. Does anyone care? A compromise position is to keep the 2 Python packages separate -- since they pull in heavier dependencies (python et al) -- but roll the rest of the boost shared libs together. At this point, I must admit that I'm sick of boost packaging and am leaning towards fixing the remaining package bugs and uploading 1.35 with all the 29 or so existing packages. Even if we do that, we can always revisit this decision for 1.36, so I'm interested in hearing your thoughts. Cheers, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
Steve M. Robbins [EMAIL PROTECTED] writes: I see some value in the granularity of having each shared lib live on its own: a system that needs only Boost.Regexp doesn't have to pay the disk space for also having Boost.Python. But maybe it's not so important. Does anyone care? Absolutely. As a user of boost, I only want the specific libraries my packages use installed, otherwise there's a number of extra libraries to be installed for no reason at all. I really don't want the extra bloat. A compromise position is to keep the 2 Python packages separate -- since they pull in heavier dependencies (python et al) -- but roll the rest of the boost shared libs together. Personally, I like the existing separate packages for each bit of boost, and I would really like that kept if at all possible. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpU5q9AijN41.pgp Description: PGP signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Sat, May 03, 2008 at 12:15:39AM -0500, Steve M. Robbins wrote: On Tue, Apr 29, 2008 at 01:14:45PM +0200, Domenico Andreoli wrote: On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: 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. second option, absolutely. Good. I'm planning to assume that the 1.35.x releases are all approximately API-compatible, so I'm naming the packages libboost-foo1.35-dev. Any objection to that? My headache now is that there are 13 -dev packages in Boost. One (libboost1.35-dev) contains 60+ header-only libraries, while the others each contain 1 library that happens to build a shared object. This overhead creates a nonnegligible amount of complexity and generates bugs (e.g. #457654, #478782). Is there any value to this granularity? I can't see any. If there are no objections, I'm leaning towards collapsing all the -dev packages into libboost1.35-dev -- and rolling bcp into it, as well. I'll probably keep libboost-python1.35-dev separate (with pyste rolled into it). Your thoughts? please, proceed. ciao, Domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Tue, Apr 29, 2008 at 01:14:45PM +0200, Domenico Andreoli wrote: On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: 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. second option, absolutely. Good. I'm planning to assume that the 1.35.x releases are all approximately API-compatible, so I'm naming the packages libboost-foo1.35-dev. Any objection to that? My headache now is that there are 13 -dev packages in Boost. One (libboost1.35-dev) contains 60+ header-only libraries, while the others each contain 1 library that happens to build a shared object. This overhead creates a nonnegligible amount of complexity and generates bugs (e.g. #457654, #478782). Is there any value to this granularity? I can't see any. If there are no objections, I'm leaning towards collapsing all the -dev packages into libboost1.35-dev -- and rolling bcp into it, as well. I'll probably keep libboost-python1.35-dev separate (with pyste rolled into it). Your thoughts? Thanks, -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
On Tue, Apr 29, 2008 at 12:22:24AM -0500, Steve M. Robbins wrote: 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. second option, absolutely. we (I) do not want boost to proliferate in the archive, one version is already demanding for free-time developers. this is only a trick to ease transitions and include newer versions also in late release cycles like current one. cheers, domenico -[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-boost-devel] Bug#473752: Bug#473752: Bug#473752: Boost 1.35 has been released
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 signature.asc Description: Digital signature
