[oi-dev] SFE repository an g++ libraries in /hipster

[Alex Viskovatoff]

Hi,

Sorry for coming to this discussion late.

On 10/14/13 11:13 AM, Alexander Pyhalov wrote:
> Hello.
> I'd like to know your opinion on the following issue. As we are moving
> to gcc-only (or at least gcc-mostly) build in /hipster we have a problem
> of providing both versions of Sun CC-compiled C++ libraries and GCC
> compiled C++ libraries. The decision is to be made what to do with this
> issue in the future. But for the now I'm starting to deliver
> G++-compiled libraries in /usr/g++. Evidently, it sometimes breaks SFE.
>
> For example, with recent push of gcc-compiled icu we delivered ICU
> 4.6.1, while SFE boost package expects to find icu 4.8.1 under /usr/g++.
>
> We need some coordination (for example, on library versions), or perhaps
> a separate build of SFE on /hipster. What do you think on the subject?

I am waiting to get a build zone and public repo for SFE builds catering 
specifically to hipster. There is no question that hipster needs its own 
build of SFE packages. What remains to be seen is how heavily SFE specs 
themselves need to be modified to work with hipster. Ideally, as little 
as possible.

hipster/ is supposed to be bleeding edge. so why does it sometimes 
deliver packages at versions older than SFE does? icu is a case in 
point. if you see that SFE is at icu 4.8.1, why don't you just make 
hipster's icu at the same (or a higher) version? Then nothing would be 
broken. SFE's boost would simply use hipster's icu lib for its hipster 
build in that case.

Ruby is another case in point. Just a few days ago, I had to update 
SFE's spec for Ruby and build it myself, because hipster delivers a 
version of Ruby that is too old for something I was building. Why isn't 
hipster at the current stable release of Ruby, which is 2.1.0?

In general, SFE IPS builds for hipster (as well as the SFE specs 
themselves) should accommodate to new packages that are delivered by 
hipster which SFE previously delivered itself. (In such cases, as I 
said, it is preferable that hipster not deliver earlier versions of the 
same package as SFE delivers unless there is a good reason to deliver an 
old version.) So, if hipster one day delivers Boost, then SFE will 
accommodate itself to that. If OI/hipster for some reason decides to 
deliver an older version of Boost than SFE has been providing and 
building for some time however, problems may arise.

Best regards,

Alex