Re: [boost] Core libraries should separated from experimental libraries
Stefan Seefeld wrote:
Wait. You'd like to have releases bundle both, and you don't want to provide distinct guarantees. What's the point in this split, then ?
1) To make the life of package maintainers (e.g. debian, ubuntu) easier. 2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package. 3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this. Regards, Thomas
On 11/22/2009 03:06 PM, Thomas Klimpel wrote:
Stefan Seefeld wrote:
Wait. You'd like to have releases bundle both, and you don't want to provide distinct guarantees. What's the point in this split, then ?
1) To make the life of package maintainers (e.g. debian, ubuntu) easier.
I still don't see what change they would see.
2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package.
"from the complete package" isn't an option. Either I can obtain official stand-alone packages or I can't. Rolling them myself (no matter how little work this may practically mean) is rarely an option, especially in the industry, as it would also imply taking responsibility, aka. doing some form of maintainership.
3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this.
accidentally stable ("stable without any explicit guarantee") is only marginally better than unstable. It still means one has to re-validate everything for each version, and a 'drop-in upgrade' is probably impossible. Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
> Thomas Klimpel wrote:
> > Stefan Seefeld wrote:
> >> Wait. You'd like to have releases bundle both, and you don't want to
> >> provide distinct guarantees. What's the point in this split, then ?
> > 1) To make the life of package maintainers (e.g. debian, ubuntu) easier.
>
> I still don't see what change they would see.
You may be right that it is difficult to know the exact impact for package maintainers. Remember that my initial reply was to a package maintainer that mentioned the release frequency of boost, and that I asked why not reduce the frequency to two major releases per year. There are some linux distributions that also release two times per year, so it could indeed help them. I'm also not sure how boost is currently packaged in debian, but I believe having seen packages which didn't installed boost as a huge blob, but had a finer sub-package structure.
> > 2) To make adoption of boost in corporate environments easier,
> > by offering the option to only use the "core" package, potentially
> > cherry-picking only a few of the other libraries from the "complete" package.
>
> "from the complete package" isn't an option. Either I can obtain
> official stand-alone packages or I can't.
So dependencies between the libraries not in the core package would have to be documented (and the actual dependencies would need to guaranteed to really be not worse than documented). Packaging the release for distribution into "core" and "complete" doesn't mean that cherry-picking packages from the complete set is not official supported. You could have a Boost.Build option that installs you a library including all it's dependencies into a certain location.
> accidentally stable ("stable without any explicit guarantee") is only
> marginally better than unstable. It still means one has to re-validate
> everything for each version, and a 'drop-in upgrade' is probably impossible.
It's a bit the same as with the warning-free compile. The maintainers would strive to keep it stable. Even if you would be guaranteed that it is stable, that still wouldn't imply that you could be completely sure of this.
But it was just a suggestion, and I got the message that it won't solve the problems you see.
Regards,
Thomas
On 11/22/2009 04:06 PM, Thomas Klimpel wrote:
Stefan Seefeld wrote:
Thomas Klimpel wrote:
Stefan Seefeld wrote:
Wait. You'd like to have releases bundle both, and you don't want to provide distinct guarantees. What's the point in this split, then ?
1) To make the life of package maintainers (e.g. debian, ubuntu) easier.
I still don't see what change they would see.
You may be right that it is difficult to know the exact impact for package maintainers. Remember that my initial reply was to a package maintainer that mentioned the release frequency of boost
I don't think the release-frequency per se was the issue. The issue (as I see it) is that, with two subsequent boost releases having no guaranteed relationship to each other, a developer targetting Ubuntu, SuSE, and RedHat, would have to assume that each comes with its own "boost-like" package, instead of being able to build on the subset that are common to all of them (and which we for simplicity's sake call "core" in this context). Synchronizing boost releases with OS releases makes things only marginally better: application developers still need to target all of them, with more variability than would be necessary.
"from the complete package" isn't an option. Either I can obtain official stand-alone packages or I can't.
So dependencies between the libraries not in the core package would have to be documented (and the actual dependencies would need to guaranteed to really be not worse than documented). Packaging the release for distribution into "core" and "complete" doesn't mean that cherry-picking packages from the complete set is not official supported. You could have a Boost.Build option that installs you a library including all it's dependencies into a certain location.
Forget about boost.build. I'm talking about application developers who want to assume most of their dependencies as being "system libraries", i.e. they are more interested into binary rpms and debs, not a source tarball they need to massage to get something they can ship themselves.
accidentally stable ("stable without any explicit guarantee") is only marginally better than unstable. It still means one has to re-validate everything for each version, and a 'drop-in upgrade' is probably impossible.
It's a bit the same as with the warning-free compile. The maintainers would strive to keep it stable. Even if you would be guaranteed that it is stable, that still wouldn't imply that you could be completely sure of this.
Of course, I always need to validate my own product against any change in "third-party" libs. It's never black or white. Stefan -- ...ich hab' noch einen Koffer in Berlin...
participants (2)
-
Stefan Seefeld -
Thomas Klimpel