Re: [boost] Core libraries should separated from experimental libraries

Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2009-11-22 16:59:44

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...