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
Attachment:
signature.asc
Description: Digital signature