I've uploaded a src.rpm for boost-1.34.0, yet unreleased, to my people page. http://people.redhat.com/bkoz/boost-1.34.0/ There are also binary packages for x86. I'm hoping to get some feedback on this rpm, and boost packaging changes, before beginning the process of migrating to this codebase and spec file for future Fedora or Red Hat releases. Interested hackers are encouraged to download these files and play with them. Of course, before this would be pushed, 1.34.0 would have to be released, and testing would have to be successful. Given the current regression testing results for the release branch, it is likely that this will not happen in the near future. In addition, I'm curious to see if there is anybody who would like to help maintain this package. best, benjamin
Benjamin Kosnik wrote:
I've uploaded a src.rpm for boost-1.34.0, yet unreleased, to my people page.
http://people.redhat.com/bkoz/boost-1.34.0/
There are also binary packages for x86.
I'm hoping to get some feedback on this rpm, and boost packaging changes, before beginning the process of migrating to this codebase and spec file for future Fedora or Red Hat releases. Interested hackers are encouraged to download these files and play with them.
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ? I think the more packages get added to boost the more urgent an issue this becomes. This may even be something to be addressed not only at the packaging level but one level down in the way boost source code (and the build system) is organized... Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ?
Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO. It's certainly possible, just more work. I see this as more of an advantage for the debuginfo packages.
I think the more packages get added to boost the more urgent an issue this becomes.
Certainly, this is a concern.
This may even be something to be addressed not only at the packaging level but one level down in the way boost source code (and the build system) is organized...
Yes. Well, if the boost build system goes this way, then so would this packaging. best, benjamin
Benjamin Kosnik wrote:
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ?
Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO.
Ah well. Unfortunately not everybody agrees that boost is not modular enough. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld escreveu:
Benjamin Kosnik wrote:
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ? Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO.
Ah well. Unfortunately not everybody agrees that boost is not modular enough.
I've seen this discussion before, and never saw any proof of concept for this modular release approach. But maybe I just missed it, I'm not that alert. -- Pedro Lamarão
Pedro Lamarão wrote:
Stefan Seefeld escreveu:
Benjamin Kosnik wrote:
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ? Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO. Ah well. Unfortunately not everybody agrees that boost is not modular enough.
I've seen this discussion before, and never saw any proof of concept for this modular release approach.
I'm not sure what you mean by 'proof of concept'. Use cases I have in mind include: * The ability to install individual components. * The ability to build a dependent component such that prerequisite components may be preinstalled or part of the same tree (say, on my FC6 laptop, I have 'boost.core' and 'boost.graph' rpms installed, and want to compile 'boost.python' from mainline). * The ability to run test suites for components, with all prerequisite components already installed. I believe that having support for the above would make life for (almost) everyone much easier, since components could be developed, built, tested, and released (oh, and used ! :-) ) more independently. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Pedro Lamarão wrote:
Benjamin Kosnik wrote:
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ? Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO. Ah well. Unfortunately not everybody agrees that boost is not modular enough. I've seen this discussion before, and never saw any proof of concept for
Stefan Seefeld escreveu: this modular release approach.
I'm not sure what you mean by 'proof of concept'. Use cases I have in mind include:
* The ability to install individual components. * The ability to build a dependent component such that prerequisite components may be preinstalled or part of the same tree (say, on my FC6 laptop, I have 'boost.core' and 'boost.graph' rpms installed, and want to compile 'boost.python' from mainline). * The ability to run test suites for components, with all prerequisite components already installed.
I believe that having support for the above would make life for (almost) everyone much easier, since components could be developed, built, tested, and released (oh, and used ! :-) ) more independently.
There's all sorts of things that have already, and can be done. Everyone that wants a smaller boost can use bcp: http://www.boost.org/tools/bcp/bcp.html. bjam can already run tests for individual libs as desired. For the TR1 inclined, John Maddock has created an alpha of a TR1 only distro: http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=189383 On other Linux systems boost is already 'split up'. On my ubuntu system Boost has components for each 'built library', tools, docs, etc. Here's the relevant output of 'apt-get search boost' libboost-dev - Boost C++ Libraries development files libboost-python-dev - Boost.Python Library development files libboost-python1.33.1 - Boost.Python Library bcp - tool for extracting subsets of Boost C++ Libraries bjam - Software build tool boost-build - Build system libboost-date-time-dev - set of date-time libraries based on generic programming concepts libboost-date-time1.33.1 - set of date-time libraries based on generic programming concepts libboost-dbg - Boost C++ Libraries with debug symbols libboost-doc - Boost.org libraries documentation libboost-filesystem-dev - filesystem operations (portable paths, iteration over directories, etc) in C++ libboost-filesystem1.33.1 - filesystem operations (portable paths, iteration over directories, etc) in C++ libboost-graph-dev - generic graph components and algorithms in C++ libboost-graph1.33.1 - generic graph components and algorithms in C++ libboost-iostreams-dev - Boost.Iostreams Library development files libboost-iostreams1.33.1 - Boost.Iostreams Library libboost-program-options-dev - program options library for C++ libboost-program-options1.33.1 - program options library for C++ libboost-regex-dev - regular expression library for C++ libboost-regex1.33.1 - regular expression library for C++ libboost-serialization-dev - serialization library for C++ libboost-signals-dev - managed signals and slots library for C++ libboost-signals1.33.1 - managed signals and slots library for C++ libboost-test-dev - components for writing and executing test suites libboost-test1.33.1 - components for writing and executing test suites libboost-thread-dev - portable C++ multi-threading libboost-thread1.33.1 - portable C++ multi-threading libboost-wave-dev - C99/C++ preprocessor library I'd suggest that the RPM based distros might want to follow the lead of ubuntu if that want smaller granularity boost packages. Jeff
Jeff Garland wrote:
Stefan Seefeld wrote:
Pedro Lamarão wrote:
Benjamin Kosnik wrote:
Has any thought been put into releasing multiple split boost packages containing orthogonal functionality (boost.python, boost.wave, boost.serialization, etc.) ? Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO. Ah well. Unfortunately not everybody agrees that boost is not modular enough. I've seen this discussion before, and never saw any proof of concept for
Stefan Seefeld escreveu: this modular release approach. I'm not sure what you mean by 'proof of concept'. Use cases I have in mind include:
* The ability to install individual components. * The ability to build a dependent component such that prerequisite components may be preinstalled or part of the same tree (say, on my FC6 laptop, I have 'boost.core' and 'boost.graph' rpms installed, and want to compile 'boost.python' from mainline). * The ability to run test suites for components, with all prerequisite components already installed.
I believe that having support for the above would make life for (almost) everyone much easier, since components could be developed, built, tested, and released (oh, and used ! :-) ) more independently.
There's all sorts of things that have already, and can be done. Everyone that wants a smaller boost can use bcp: http://www.boost.org/tools/bcp/bcp.html.
The danger here is to let users (and individual packagers) decide where to draw the line(s). As a result, package layout differs between platforms / distributions, making life hard for users. I think there is great value in boost.org providing guidlines about how to split, so users get the same, no matter whether they install from source, binary packages, or whatever. (Example: I'm developing an application using some boost components, and I want it to be portable, using make / autotools if available. What should I check for ? Even among GNU/Linux distributions this may vary wildly !)
bjam can already run tests for individual libs as desired.
But can it run test on one component that is being built against preinstalled prerequisite components ? I still need a full source tree, no ? And, it's not as easy as it could, so users refrain from doing it, so boost.org doesn't get as much help as it could.
On other Linux systems boost is already 'split up'. On my ubuntu system Boost has components for each 'built library', tools, docs, etc. Here's the relevant output of 'apt-get search boost'
Right, but as this split isn't christened by boost.org, other distros will most likely reinvent their own way. RH / FC packages right now aren't split, which is the point of my original reply.
I'd suggest that the RPM based distros might want to follow the lead of ubuntu if that want smaller granularity boost packages.
Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Jeff Garland wrote:
Stefan Seefeld wrote:
Pedro Lamarão wrote:
Benjamin Kosnik wrote:
> Has any thought been put into releasing multiple split boost packages > containing orthogonal functionality (boost.python, boost.wave, boost.serialization, > etc.) ? Some. There are some intra-dependencies, and the split would add more complications to an already too-complicated build process IMHO. Ah well. Unfortunately not everybody agrees that boost is not modular enough. I've seen this discussion before, and never saw any proof of concept for
Stefan Seefeld escreveu: this modular release approach. I'm not sure what you mean by 'proof of concept'. Use cases I have in mind include:
* The ability to install individual components. * The ability to build a dependent component such that prerequisite components may be preinstalled or part of the same tree (say, on my FC6 laptop, I have 'boost.core' and 'boost.graph' rpms installed, and want to compile 'boost.python' from mainline). * The ability to run test suites for components, with all prerequisite components already installed.
I believe that having support for the above would make life for (almost) everyone much easier, since components could be developed, built, tested, and released (oh, and used ! :-) ) more independently. There's all sorts of things that have already, and can be done. Everyone that wants a smaller boost can use bcp: http://www.boost.org/tools/bcp/bcp.html.
The danger here is to let users (and individual packagers) decide where to draw the line(s). As a result, package layout differs between platforms / distributions, making life hard for users. I think there is great value in boost.org providing guidlines about how to split, so users get the same, no matter whether they install from source, binary packages, or whatever.
Personally, I think the ubuntu split makes sense. Tools, docs in their own packages. Each library with an actual lib on it's own. The base headers on their own. But setting a standard like this requires an enormous amount of effort. Someone has to write it up in detail. Then they have to get agreement. As with most OSS projects we run on volunteer labor around here, but if you're volunteering ;-)
(Example: I'm developing an application using some boost components, and I want it to be portable, using make / autotools if available. What should I check for ? Even among GNU/Linux distributions this may vary wildly !)
Sure, I agree, it's not totally automated. Actually, now that I'm thinking about it isn't there another rpm setup in the source tree somewhere contributed by Dan Marsden or someone?
bjam can already run tests for individual libs as desired.
But can it run test on one component that is being built against preinstalled prerequisite components ? I still need a full source tree, no ?
Yes.
And, it's not as easy as it could, so users refrain from doing it, so boost.org doesn't get as much help as it could.
On other Linux systems boost is already 'split up'. On my ubuntu system Boost has components for each 'built library', tools, docs, etc. Here's the relevant output of 'apt-get search boost'
Right, but as this split isn't christened by boost.org, other distros will most likely reinvent their own way. RH / FC packages right now aren't split, which is the point of my original reply.
Well, again we'd need some sort of project / process to approve the layout. For that we'd need a concrete proposal, for which someone would need to do the work. Sorry to be a bit skeptical here, but given that we can't even get 1.34 done it seems hard to imagine we have time to worry about packaging. Jeff
Jeff Garland wrote:
Well, again we'd need some sort of project / process to approve the layout. For that we'd need a concrete proposal, for which someone would need to do the work.
Sorry to be a bit skeptical here, but given that we can't even get 1.34 done it seems hard to imagine we have time to worry about packaging.
Actually I think the timing couldn't be any better ! I'm certainly not proposing to change any code / infrastructure right now. But as everybody right now is painfully aware of the limitations of the current release process, I'd hope that it may be possible to find some motivation / momentum to start thinking about enhancements for the post 1.34 work. FWIW, I believe that the required infrastructure for the use cases I suggested earlier may be straight forward to add, and doesn't require any formal process. However, all this certainly also fits into a wider discussion about build / test / release infrastructure and process, which, then, needs a broader discussion. There ought to be a way out of this deadlock... Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld escreveu:
Jeff Garland wrote:
Well, again we'd need some sort of project / process to approve the layout. For that we'd need a concrete proposal, for which someone would need to do the work.
Sorry to be a bit skeptical here, but given that we can't even get 1.34 done it seems hard to imagine we have time to worry about packaging.
[SNIP]
There ought to be a way out of this deadlock...
The way out of this deadlock is for some interested party to actually produce a spec file (or something similar) that could actually be processed to produce the desired split packages. This spec file will, then, be a _real_ proposal everybody else could nitpick upon. -- Pedro Lamarão
Pedro Lamarão wrote:
Stefan Seefeld escreveu:
Jeff Garland wrote:
Well, again we'd need some sort of project / process to approve the layout. For that we'd need a concrete proposal, for which someone would need to do the work.
Sorry to be a bit skeptical here, but given that we can't even get 1.34 done it seems hard to imagine we have time to worry about packaging.
[SNIP]
There ought to be a way out of this deadlock...
The way out of this deadlock is for some interested party to actually produce a spec file (or something similar) that could actually be processed to produce the desired split packages.
This spec file will, then, be a _real_ proposal everybody else could nitpick upon.
FWIW, by 'deadlock' I was actually referring to the current release 'process', and any enhancements that have to wait until it is done. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (4)
-
Benjamin Kosnik -
Jeff Garland -
Pedro Lamarão -
Stefan Seefeld